develooper Front page | | Postings from September 2000

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

Thread Previous | Thread Next
Ilya Zakharevich
September 22, 2000 12:31
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Message ID:
On Fri, Sep 22, 2000 at 11:17:40AM -0400, Karl Glazebrook wrote:
[Cryptocontext is:]

> >   f(3*@a)
> > 
> > would typically be a list context - and suddently instead of 3*(1+$#a)
> > you get C<map 3*$_, @a>.
> This is true, what I would propose is we declare 3*(1+$#a) outmoded and
> always have it mean C<map 3*$_, @a> in all contexts.

You are trading a frequently used shortcut @a == 1 + $#a for a 
rarely-used-but-beautiful/intuitive semantic.  I'm not sure it is a win.


  $x = 3 * @_;

suddently being equivalent to

  $x = @_;

does not look very promising...

> > Why?  Currently you can make them look like references to array.  See
> > Math::Pari for an implementation.  Overloading '@{}' gives yet another
> > way to do this.
> True but the user has to remember 'owe I am now using a special PDL
> array which means I have to always use a reference to it rather than
> treat it like a perl array'. Not good.

No, you do not use "a special PDL array", you use "a vector".
A subtle change in wording - and no conflict.

> This is true, but inelegant. If perl @x arrays are not considered useful
> why not get rid of them and always use references?

Actually, this is what Perl is using internally (they are
softreferences==globs, but who cares?).


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About