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 > > $x.foo > > 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 > given, > > 1,2,3.foo > > is still going to mean > > 1, 2, (3.foo) > > instead of the desired > > postfix:<foo>(1,2,3) > > 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? > > 1,2,3\foo > (1,2,3)foo > (1,2,3).foo > postfix:<foo>(1,2,3) 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. Larry
