Dan Sugalski wrote:
> On Thu, 31 Aug 2000, Jeremy Howard wrote:
> > Karl Glazebrook wrote:
> > > To access a single element we want
> > >
> > > $a[$i,$j,$k]
> > >
> > But this already means "the $i, $j, and $k" elements of a list. It is a
very
> > frequently used construct--I think that changing it will be impossible,
and
> > that creating a new data type that acts contrary to this would be highly
> > confusing.
>
> It doesn't, though. It actually means the $k element of the array $a--for
> the $i, $j, and $k elements you'd need a @ in front of the slice.
>
That's true. I still think it's confusing to have such similar syntaxes mean
such different things. I'd also like to be able to say:
@a[[$i,$j,$k], [$x,$y,$z]]
to get two points.
> <...>
> Either way, I expect the parser would know what you were doing and Do The
> Right Thing, though personally I'd rather we didn't overload the LOL
> syntax this way. (We'll do it if it comes to that, though) You might
> consider an alternative as part of the RFC that uses new syntax
> rather than overloading the old.
>
I'm not sure I following... We're not overloading the old notation, but
instead:
- Implementing it more efficiently if the data fits a hypercube structure
- Adding notation to get at elements more easily:
* @a[[$i,$j,$k], [$x,$y,$z]]
* @a[$i,$x][$j,$y][$k,$z]
> This is just personal preference--I grew up programming in languages that
> had real multidimensional arrays, and I'd just as soon we added them to
> perl for real. (Real being in a user-visible sense--I know we'll do it for
> real under the hood)
>
I want them 'for real' too, both in the syntactic and implementation sense.
Just because they happen to support the LOL syntax, I don't yet see how they
are less than 'real'. They can be indexed directly, sliced, iterated through
any dimension, and so forth. The only difference I can see is whether we
have a type prefix in addition to '@'. What are the syntactic features you
are envisioning that would make n-dim arrays more user visibly real?
