On Sat, Apr 17, 2004 at 01:07:44PM -0500, Abhijit A. Mahabal wrote:
: I do not understand one of the examples in the Use of methods/the dot
: notation section:
:
: $obj.method ($x + $y) + $z
:
: >From the earlier examples (like $obj.method +1), I got the impression that
: you look ahead until you find a term or an operator. In the example above,
: isn't ($x + $y) a full term, all by itself, and in that case would not
: this mean ($obj.method($x + $y)) + $z, the same as the other call it is
: contrasted with:
:
: $obj.method($x + $y) + $z
:
: What am I missing?
The distinction is not term/operator exactly. It's a four-way distinction
between
definitely a postfix op -> () hold arguments, otherwise no arguments
definitely a binary op -> there are no arguments
ambiguous -> require disambiguation
definitely a term -> treat method as list operator
where the last category assumes that the term indicates the first item
in an expression. (Note that a definite unary operator is the beginning
of a term.)
The basic underlying motivation is to allow methods a list operators:
$my.for 1..3 {...}
Now, we haven't actually defined what puts the method call into which
category. But the rather obvious poler opposites are
$obj.meth, -> obviously not arguments
$obj.meth $foo,$bar -> obviously arguments
If the rules get skewed one way or the other to eliminate the ambiguos
middle category, I'd say that we tend to give the benefit of the
doubt to the list, and you have to put a "stopper" like comma or a
right bracket or brace, or put explicit empty parens, if you want to
pass no arguments. But if we can unambiguously define what's ambiguous :-)
then it might be useful to force people to clarify what they mean, just
for readability.
Larry
