On Wed, Mar 26, 2008 at 07:32:23PM -0600, Thom Boyer wrote:
> Question: given
> ($x)++ # no whitespace, so postfix?
> is ++ postfix, or infix?
That is postfix. Any infix that could be confused with a postfix
requires intervening whitespace.
> Now, I think that
> is a method call, even if there's a postfix:<foo> declaration in scope. And
> that's a problem, because, no matter what precedence postfix:<foo> was
> is still going to mean
> 1, 2, (3.foo)
> instead of the desired
> so Larry has proposed
> 1,2,3\foo # means: postfix:<foo>(1, 2, 3)
> as a way to get the desired meaning without having to resort to parentheses.
> So the point is that a nospace unspace acts like dot, in that it turns the
> following operator into a postfix operator. But it doesn't have the
> undesired characteristic that it turns an intended postfix operator into a
> method dispatch. Have I got that right, or am I still wandering in a
> wilderness that is completely disconnected from Larry's proposal?
The .++ form is still not a method (single) dispatch, just an alternate
form of the postfix, which is a multi dispatch. The basic problem
is that .i is ambiguous, and by the current standard grammar is
not resolved by LTM because it's a tie. We could maybe fix that by
changing it so the "meth" part of .meth isn't counted as part of the
same token, but right now it is. Or we could bias .meth forms toward
single dispatch (which might work the same, depending on whether there's
an equivalent method definition, which often there is, especially if
the multi is defined as just an exported method).
> Final question: I think these are all equivalent. Are they?
At the moment, the .foo form is officially ambiguous, so might end up
going through single dispatch instead of multi dispatch. To the casual
reader it looks like it should be single dispatch. That's what
is bugging me. Well, one of the things...
The current tie-breaker on longest token matching is to use rule
ordering, but that's not terribly robust.