PROPOSAL: opSeq()

[Frits van Bommel]

Russell Lewis wrote:
> Bill Baxter wrote:
>> It's an interesting idea.  Are you sure it doesn't kill 
>> the-ease-of-parsing requirement for the grammar?
> 
> That is something that I have worried about, as well, and I haven't done 
> a rock-solid analysis of it.  However, my hand-waving argument is that 
> we parse the code without any knowledge of the types (we don't know 
> which are opSeq handlers and which are not).  If our parsing shows us 
> that we have a sequence of expressions without any sort of operator 
> between them, then we interpret that using the opSeq parse rule:
> 
>     expression:
>         expression expression ...
> 
> Then, in semantic analysis, we would decide whether that syntax is valid 
> or not.  Since opSeq is right-associative, we start at the far-right of 
> any chain of expressions, and see if the next-to-last expression is an 
> opSeq handler; if so, it must take 1 argument, and the type must match 
> the rightmost expression.  If not, then we work left, and so on.
> 
> Mechanically, I think I can argue that this doesn't make the parser any 
> more complex.  What I don't know for sure, yet, is whether it introduces 
> ambiguities into the grammar.  Those often require a tool to find. :(

Well, one ambiguity is stuff like: "foo 1 -2". Is this foo.opSeq(1 - 2) 
(i.e. foo.opSeq(-1)) or foo.opSeq(1, -2)?
Ditto for '~' (concatenation versus bitwise negation), '&' (bitwise-and 
versus address-of), '!' (template instantiation versus logical 
negation), '.' ("member of" versus "look up in the global scope"), '+' 
(addition versus numeric identity function), '*' (multiplication versus 
dereferencing).

If you only allow _unexpected_ expressions, as you suggest, that would 
mean always choosing the first alternative above. That would mean you'd 
have to disambiguate the unary versions of those operators by placing 
them in parentheses: "foo 1 (-2)" instead of the initial example.
But that leaves another ambiguity: what about "foo x (-2)"? That would 
translate to foo.opSeq(x(-2)). I don't think this one can be resolved, 
even placing parentheses around x doesn't work. For example, if x is a 
delegate, the expression would mean the same thing with or without 
parentheses around it, so there would be no way to call Foo.opSeq(void 
delegate(int), int) except explicitly.

Besides, if you're going to place parentheses around all the operands 
you might as well overload opCall and be done with it, without any 
syntax extensions or added ambiguity at all.