develooper Front page | | Postings from September 2000

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

Thread Previous | Thread Next
Karl Glazebrook
September 21, 2000 12:26
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Message ID:
Ilya Zakharevich wrote:
> As shipped: no.  But if this is made a primitive (which I would not
> like), then the only change which is needed is to make the
> tie::multi::range() token to be followed by 3 numbers.
> [Aside: Why not make ternary-range operator into 10 :: 20 :: 2 ?]

That would work. My point is that having a stride is a fundamental
feature in other array languages (IDL, Matlab, PDL) and would be
useful in the perl core.

> > Finally as an overload expert what do you think about the proposals
> > to make arrays overloadable objects so one can say things like:
> >
> > @x = 3 * @y;
> This is not an overloading issue, this is the context resolution
> issue.  IMO, the cryptocontext turns out to be evil with an exception
> of extremely short scripts - and this is with what we have now.
> A proposal like this would make a nuisance into a nightmare.  Yes, it
> looks nice, but it contradicts many rules, so in the long run it is
> going to be a significant step back.
> ...Unless the whole idea of cryptocontext is turned to become something else...

I am not sure what you mean by "cryptocontext"?

I guess the motivation here is to make non-core arrays (such as PDL
objects) look as much as possible like Perl arrays to simplify the
appearance to users.

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

I can see that allowing expressions on @x would require considerable
changes to perl core.

Is there a nice way to resolve this problem?


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