Aaron Sherman writes:
: On Mon, 2002-04-08 at 13:01, Jonathan E. Paton wrote:
:
: > I'm I beating this point to death, or do I have to write
: > the RPC:
: >
: > "Keep the {} and [] notation for hashes and arrays"
: >
: > or
: >
: > "Save our array!"
:
: Let's boil this RFC down to one short phrase:
:
: If {} goes away in Perl6, then everything you've heard about Perl6 being
: "not really all that different from Perl5" is either a lie or a damned
: lie. People keep saying "it's just Perl5, but instead of syntax X, you
: now use syntax Y". Well, as both X and Y lists grow longer....
Your turn to panic, eh? :-)
Look, {} for hash subscripts is not going away in Perl 6. It's too
useful as documentation, if nothing else.
That being said, with an efficient tie-like interface for array
variables, it doesn't really matter if [] is passed something other
than an integer, as long as the implementation is expecting it. The
reason we're making ties declarative in Perl 6 is so that we don't have
to pessimize all arrays with that assumption, or even all tied arrays.
In the absence of such a declaration, the subscripts are "known" to be
consecutive integers, and the compiler is free to optimize based on
that assumption. Hash subscripts make no such promise.
: I know this is harsh, but really folks, you're pulling Perl apart
: looking at a half-dozen good features and building a new language around
: them. I don't fault you for this (it's a great way to come up with a new
: language), but I'm beginning to get the feeling that going from Perl5 to
: Perl6 is going to be almost the same level of effort as going from
: Pascal to ANSI C!
:
: Also, just wondering:
:
: $_[_][EMAIL PROTECTED] _=_0_-_
:
: does that work the way I expect it to?
Well, the $_ isn't a member of @_, if that's what you were expecting.
It's a syntax error after the second _, since that's a built-in unary
operator without a default. [...] will never autoquote like {...}.
It's just possible that you could get away with it by overloading _
to be argumentless:
sub _ () { ... }
Leaving that aside, the third _ is a valid binary _ for string concatenation..
The fourth _ is a valid part of @_, and a term is expected, so that's okay.
The fifth _ is a valid method name, and is probably in fact a universal
method corresponding to the universal unary _ operator.
The sixth _ is a valid part of an _= assignment operator.
The seventh _ is a valid unary _.
The eighth _ is not a part of the preceding number because numeric _
must have digits on both sides. So an operator is expected, meaning _
will be taken as another binary _.
Now a term is expected, so the - is unary, and the _ again is illegal
unless an argumentless _ has been declared.
I hope the meaning of your expression is now completely clear. :-)
Larry
