Mark Cogan wrote:
> At 11:11 PM 8/15/00 -0400, Chaim Frenkel wrote:
> >You are missing the beauty of vector/matrix operations.
>
> No, I'm not; I'm opining that the vast majority of Perl users don't need
to
> do vector/matrix ops, and that they don't belong in the core.
>
The vast majority of Perl 5 users don't, because it's a pain in Perl 5. They
use other languages instead, but those other languages aren't nearly as nice
as Perl in almost every other way. Why not open up Perl for a whole new
class of folks?
>
> >The math folks
> >really would like to be able to describe the operation wanted and have
> >perl do the optimization.
>
> Then maybe they should use a dedicate math extension to Perl, like PDL.
>
You've got to be joking! You think PDL is a simple convenient add-on to Perl
that provides these features? It's not! PDL is an astonishing hack by some
incredibly clever people, but it still _does_not_ support array notation,
and optimised loops have to be written in yet *another* language named PP,
which is compiled into C by a special compiler, and linked into the program.
This is the absolute best that can be done right now, and the PDL folks
deserve a medal for what they've achieved. But really, no-one should have to
jump through these kinds of hoops!
> >Would adding another character be helpful
> >
> > @result = @a x|| @b?
> >
> > @result = @a ||| @b?
> >
> >or perhaps a modifier?
> >
> > @result = @a || @b forall;
> >
> >(Blech, that just doesn read right.)
>
> Perhaps we just need a two-list map, which aliases $a and $b like sort():
>
> @result = map {$a || $b} @a,@b;
>
No. It would need to be n-list, and it would have to handle slices and
lazily generated lists incredibly cleverly. map is too generic to easily
make the kinds of optimisations required for array notation.
I don't know how to convince you here. There's a feature that, if added to
Perl, would make my life and many of my collegues lives easier. I know this
for a fact because I've used it elsewhere. I doesn't break much that can't
fairly easily be incorporated into P52P6, it's a generic abstraction that
applies to many things other than numeric programming (it's great for string
manipulation!), and it's proved itself elsewhere.
I'm not ruling out a modifier, as Chaim outlined, although I agree that the
word 'blech' comes to mind. But this is too good an opportunity to see it
just disappear. Have a look at the examples in RFCs 23, 76, 81, 82, 90, and
91, which combine together to provide as strong a data manipulation language
as you'll find anywhere. Over the next few days I'll be updating these to
include more examples, particularly non-numeric ones.
