Bryan C.Warnock wrote:
> On Wed, 09 Aug 2000, Jeremy Howard wrote:
> > Of course, if the user wants to overload this behaviour, we should let
them.
> > In the multiplication example, however, I would have thought that 'x' is
a
> > more suitable inner product operator...
>
> And that seems to be where most of the critics of non-scalar arithmetic
> and operator overloading have most of the problems. (Provided, of
> course, that you're limited to operator overloading and not operator
> creation, as I believe Smalltalk allows.)
>
Actually, I think we're in agreement (this comment about 'x' was really an
aside--I'm not proposing about putting that into the core... just make sure
we can overload it).
> <...>
>
> Perl could probably get away with better defining a strict (and
> consistent) set of operations of vectors (vectors in a CS sense of the
> word, vice a strictly math sense of the word) that behaved in a Perlish
> way, and not necessary a mathematical way, but I think matrix
> manipulation unadorned in bare Perl code will be difficult to make
> consistent with the rest of the language, or even accurately
> represented.
>
Exactly. Let's make sure that:
- ...'@a op @b' in a list context always does a component-wise operation
- ...that this can be overload
- ...that Perl functions in a list context apply themselves to each element
of the list (where it makes sense for them to do so)
I'm happy to expand this into an RFC, if there's no major objections.
> I like the work that PDL has done, and would like to see a way to make
> (at least simple) matrix calculations more inline, but it may end up
> too counter-intuitive (or obtrusive) to programmers using lists and
> arrays in another context.
>
I think that's OK. Perl should like like Perl, not like Mathematica. But we
can still provide the power of the notation and inlined calculations. It's
like when Perl OO was introduced in Perl 5--it didn't look much like OO to
C++ programmers, but it was Perlish, and it was OO.
