On Sun, 6 Aug 2000, Jeremy Howard wrote:
> > > > * Built-ins: min() and max() functions and acceptors
> > > >
> > > > * Built-ins: reduce() function
> > > >
> > > > * Subroutines: lazy evaluation of argument lists
> > > >
> > > > * Superpositions: vector operations via superpositions
> >
> > Couldn't see those either. Could you refer to the actual RFC #s, please?
>
> As I mentioned, not all Damian's RFCs exist yet. These are the ones that
> he's promised are coming (along with generalised iterators).
> >
> > <...> From our point of view one question is: assuming
> > that there still is a need for compact numerical objects (PDLs) as
> > opposed to conventional perl arrays (for reasons of efficiency and
> > memory consumption) will those
> > compile time optimizations also be accessible to PDL objects?
> >
> Do we really need PDL objects in perl 6? How about we investigate building
> compact arrays into the language? We're already talking about how we can add
> typing to the language--I would have thought that if these semantics make it
> in, we could look to optimise how numeric types are stored.
>
> I think we should look to remove the distinction between 'stuff that works
> in PDL' and 'stuff that works in perl'. To do this I guess we need an RFC
> proposing compact array storage for numeric data. Most of the rest of PDL
> core is already proposed in one form or another. Stuff like SLATEC support
> still belongs in external modules, of course.
Again, sorry that I can only offer support from the sidelines and not take
up the task of writing an RFC. One VERY important thing to remember about
the compact data types that PDL deals with is that of smart pointers: e.g.
a slice or a diagonal of a matrix is not a copy: it's a smart reference to
the originals, and changing the values there will change the originals.
This functionality is crucial to have for a good numerical language. So if
compact arrays go in, please make sure that implementing such smart
pointer arrays is possible, efficient and easy.
PDL currently supports affine transformations but other kinds of
transforms would be interesting. But to compile to C there need to be few
types, unless a JIT compiler is included in the plans for perl 6.
Tuomas
