[EMAIL PROTECTED] writes:
: I take it the existing C<...> operator would be unaffected?
Essentially. The lexer is (and will continue to be) quite aware of the
difference between terms and operators.
The interesting thing about ... is that you have to be able to
deal with it a statement with an implied semicolon:
print "foo";
...
print "bar";
Either that, or it's a funny unary operator that can take 0 or 1 argument.
That might let you parse these too:
print (1, 2, 3, ...) or die;
or this:
print 1, 2, 3, ... 4, 5, 6;
The problem with treating it as a low-precedence unary operator is that
it would appear to run *after* the following statement in our first
example above. And I think it's more important that ... a run-time
warning than a compile-time warning.
Another option is to treat ... as a statement where a statement is
expected, as a unary/zero-ary operator where a term is expected. (And
as the binary ... operator where an operator is expected, as it is
now. On the other hand, the scalar range (flipflop) operator is so
seldom used now that we might steal its notation for range objects even
in scalar context, and provide the flipflop operator with a little less
syntactic sugar.)
But I'd be happy with just ... as a statement. Dwimming the unary
operator may not be worth it. Especially since it might be confused
with the binary operator. Compare the unary operator in
print 1, 2, 3, ... 4, 5, 6;
with the binary operator in:
print 1, 2, 3 ... 4, 5, 6;
Larry
