On Wed, 30 Oct 2002, Austin Hastings wrote:
: --- Brent Dax <[EMAIL PROTECTED]> wrote:
: > Buddha Buck:
: > # How would you parse:
: > #
: > # @a = @b[[5]];
: >
: > A 2D array slice, since you can't hyper numbers?
: >
:
: It's hypering the [5].
I don't think so. We can't allow general expressions inside a hyper []
where it could be confused with a subscript, if for no other reason than
that people will read it first as a subscript.
In fact, [] for hyper works for postfix and prefix operators only if we
can specifically distinguish the inside operator from an expression.
An earlier message had something like this as a hyper:
@a = @b[.method];
That absolutely won't work, because [.method] is a valid subscript.
In this case it would have to be written
@a = @b[.]method;
But the general problem is just about enough to kill the whole []
idea for hyper. It's really only rescuable if we have a known set of
operators to match against. Then on the basis of the rule of matching
the longest token possible, we can have the hyper interpretation
override any interpretation as a subscript or anonymous array composer.
For example, [undef] is a vector undef only if C<undef> is a member of
that distinguished set of operators.
I think making people remember a distinguished set of operators is a
bad thing, particularly when we've gone to such great lengths to
fuzz the boundary between unary ops, argument method calls, and list
ops that just happen to have one argument at the moment.
So despite the beauty of
@a [+] @b
I think it cannot survive in its current form. It overloads square
brackets too heavily.
Larry
