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

[Karl Glazebrook]

Ilya Zakharevich wrote:
> But with Fortran such things are not *needed*.  Compilers are smart
> enough to convert (equivalents to)
> 
>   map 3*$_, 34..67

This is true, but easier (and less buggy) to say what you
exactly what you mean. 102:201:3

Anyway the idea has been proposed, it won't break Perl, we'll see
what happens.

>> 
>   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.

This of course will break perl5 code. Note mine because I always say
3*scalar(@a) because 3*@a does not look like 3*(1+$#a) to me. I don't
know how many people would depend on that feature.

There is also the problenm that we are arguing somewhat in a vacuum
as we don't know how radical perl6 (in terms of syntax changes) will
be.

Anyhow the various proposals are out there, we'll see what happens.


> 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.

> 
> > It's really hard to explain why people should use @x[1..10] for
> > perl arrays and $x->slice("1:10") for PDL arrays!
> 
> Use
> 
>   $x->[1..10]
> 
> for both.

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

Karl