Jeremy Howard wrote:
> 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.
Just in case anyone isn't aware of this:
using a "stuff'em into hash keys" N-dim array syntax, that kind of thing
is totally possible in '5 --
@a{"$i $j $k","$a $y $z"} # JH's two points
as long as you use $" for your element separator you can even
refer to the elements with lists of coordinates
$a{"@bznr"} # the element at $bznr[0], $bznr[1], $bznr[2], ...
Based on these syntax, what if optimized restricted-to-integer-key
containers used string keys that match /^\d+($"\d+)*$/ as their
keys? This seems clearer to me than mucking about with lots of
nested brackets.
@a["$i $j $k","$a $y $z"] # two points in DN n-dim syntax
An exception that defaults to printing a disablable warning would get thrown
when some non-matching string is in there;
and furthermore,
$a["@bznr"]
could skip the join and split and go straight to the n-dim access.
IMPLEMENTATION:
double-quotes directly inside sqaure container access brackets
are special cased: occurances of $" w/in them go away, leaving lists
of demensional specifiers.
FURTHERMORE:
There is room for specifying slices and such in a very natural way by
declaring some multi-dim slice specification language, which would
be in strings that do not match /^\d+($"\d+)*$/, such as ranges or
an all-existing operator, perhaps * like filename globbing, so that
an array of all elements of @a[3-dim] that have x=1, 3<=z<4 could
be obtained:
@b = @a["1 * [3:4)"] #this presumes real matrices instead of integer :)
And then you can find out what a defined element's own address is,
if these are sparse, with the :n attribute
for @b { print "reading $_ made at ${_:n}\n" }
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Kansas City Perl Mongers will meet Sept. 20th at 7:00 in
Westport Flea Market Bar & Grill http://tipjar.com/kcpm
