OK I will raise to the bait
I think it's a bit unfair to say that PDL people have failed to 'bite',
there was quite a bit of discussion on our list after your post. Also
some concern about how much of perl6 is vapourware.
I am game to take part in discussions.
It has always been apparent to me that Numerical Python is better integrated
than PDL. Some language changes in core python WERE made to accomodate it,
also Python had less syntax clutter to get around.
I definitely support embedding many of the key PDL ideas into the language
- they key one is a much easier syntax for a multi-dim slice. We are currently
driven to
$a->slice("10:100,30:200");
compared to IDL AND NumPy: a[10:100,30:200]
I'd propose simply building the a:b syntax into the core of Perl6. It's
convenient and almost standard.
perl6 should provide simple arrays, but they should be allowed to be
replaced with objects with no change of syntax. So
@a[10:100,30:200];
Would work whether @a was a perl list of lists or a PDL compact array.
So would @a * @b
Loop unrolling sounds really good, their should be hooks for objects to
provide their own implementation. Proper overloading and ability to
overload by arg type are required, i.e.
sub myfunc{ float x, complex y }
sub myfunc{ float x, float y }
Their should also be hooks for slices, for example if one is implementing
a complex objects (e.g. representing a map) - one might want a slice in
physical units instead of array indices.
I'd even propose getting rid of @a for arrays and $a for scalars and just
making the "a". I've never really liked that feature of perl - I am sure
some users agree and some disagree - might be worth taking a straw poll.
In this age where everything may (or may not) be an object are $ and @ really
required? There are too many objects types and not enough funny symbols..
even with Unicode.
Karl Glazebrook
Jeremy Howard wrote:
>
> > > BTW, I'd like to see a more lightweight currying mechanism too. The
> > > challenge is to find a 'perlish' but not heavyweight approach...
> >
> > Ah, good. I assume that having established the challenge, you'll be
> > rising to it? :-)
> >
> Yes of course. But I want to first of all see the following RFCs from Damian
> he's promised:
> ----
> > * Built-ins: min() and max() functions and acceptors
> >
> > * Built-ins: reduce() function
> >
> > * Data structures: Semi-finite (lazy) lists
> >
> > * Subroutines: higher order functions
> >
> > * Subroutines: lazy evaluation of argument lists
> >
> > * Superpositions: vector operations via superpositions
> ----
> Damian is likely to write these in a way that is nicely integrated together,
> based on past experience. What I'd then like to do is to see how these fit
> together to fill in the stuff I mentioned earlier today:
> <quote>
> - Matrix ops
> - Support for lazy evaluation
> - Compile time expression unrolling (e.g. so that $a = sum(@b*@c+@d) does
> just one loop and no memory copy, as would occur with expression templates
> in C++)
> - Ability to specify infinite lists (e.g. like in Haskell)
> - Generic programming (iterators, algorithms, etc, eg. like in the STL)
> </quote>
>
> I think the way I'd like to do this is to try and implement a couple of
> interesting bits of code that I've found are good tests of numerical
> programming environments. Stuff that just looks beautiful in Mathematica
> (which supports functional, rule-based, and procedural programming), but is
> full of loops and control structures in most languages. That way any bits
> that are missing will be pretty obvious (at least bits that matter to me!)
>
> I've tried to get input from PDL porters by cross-posting a couple of times,
> but haven't got much of a bite yet. I'm nervous about finding that we either
> reinvent the wheel, or break useful stuff that they've done... Are there any
> PDL gurus here who are interested in getting involved in some of these
> perl6-language issues?
