On Sat, May 14, 2005 at 12:51:32PM -0500, Rod Adams wrote:
: Larry Wall wrote:
:
: >On Sat, May 14, 2005 at 06:41:35PM +0200, Juerd wrote:
: >: Larry Wall skribis 2005-05-14 9:20 (-0700):
: >: > Possibly. Or we just define infix .{}. and .[]. variants, or some
: >such.
: >:
: >: The problem is that we already have @foo[] meaning the same as @foo, and
: >: an always allowed . that also allows you to put whitespace around it.
: >: This means that %foo.{}.$kv should really just be %foo.kv, if $kv eq
: >: 'kv'. I think this won't work well with two dots surrounding {}.
: >: %foo.{}$kv OTOH is currently invalid syntax, so available for
: >: assimilation. Ugly, yes, but I would never suggest actually using this
: >: operator literally -- it's fine to just have it for reduce.
: >
: >Good thing I said "or some such". :-)
: >
: >: OTOH, reduce probably just needs to be smart enough to understand
: >: postcircumfix. Perhaps whitespace helps, [{ }], in parallel with
: >: &postcircumfix:<{ }>, to avoid a conflict with an infix {}.
: >
: >Erm, I don't like tokens with spaces in the middle.
: >
: >Actually, I think Damian's original formulation is sufficiently clear.
: >
: >
:
: I read it all, and thought that it should be written:
:
: $leaf = %hash{[;] @keys};
:
: Which is taken from what Larry was talking about when he first brought
: up the [] metaop.
Yes, that should work.
: Unless, of course, there is some subtle difference between a 3-d hash
: and a hash of hashes of hashes that invalidates this.
No difference, I hope. The multidimensional notation is meant
to extend to HoH and AoA transparently (as well as HoA and AoH).
Since a variable's dimensionality is always declared (and a container
object's dimensionality generated at "new" time), we shouldn't have
to worry about whether to add dimensions or autovivify a reference.
Either there's storage already allocated, or we autovivify.
I guess the interesting question is to what extent we allow binding
of a hash or array container with the "wrong" dimensionality to a
variable with a declared shape. I can argue that one both ways,
and there are probably situations in which either approach is the
"right" one. A strict interpretation would allow the optimizer to
make more assumptions, while a loose interpretation would allow more
generic code. Pragma time? Or do we need an "is exact/inexact"
sort of thing? Of course, I suspect the PDL folks will want both
things to be true simultaneously... :-)
Larry
