Eliminating parentheses around result expression

[krame505]

Currently this is needed to avoid issues with the MDA. This is slightly annoying. This could be avoided if we instead treated a lambda expression as a unary operator.

[tedinski]

Quick Q: does this mean Copper isn't happy with a bridge production like Expr ::= MarkingTerminal Expr ?

[schwerdf]

If Copper is happy with a bridge production of that form, it should not be.

[krame505]

I just went poking around with this, and the reason we require parentheses has nothing to do with the MDA: originally it was because I didn't understand the expression concrete syntax, and added the parens as a workaround to avoid a parser ambiguity. This can be fixed by instead making the production be of the form UnaryExpr_c ::= 'lambda' ... '->' UnaryExpr_c.
However, since I added C++-style statement bodies of the form lambda (int x) -> (int) { ... return foo; }, the parens around the expr are now preventing a parse conflict for something like lambda (int x) -> (struct foo) {}. This issue, in turn, could be avoided if we dropped the (also annoying) parens around the return type. I was forced to add these because of 2 reasons:

• MDA follow spillage for TypeSpecifier_c, etc. of '{' - we could probably reasonably decide to seed this to be available for extensions, since C++ does the same.
• The ambiguity of declaring a struct in the return type - how do we parse lambda (int x) -> struct foo {}? C++ seems to handle this (reasonably) by disallowing struct declarations in lambda return types. For us to do the same, we could either introduce a high-precedence '{' terminal into the follow set for TypeSpecifier_c (ugh), or refactor the host grammar. I'm in favor of the latter, I'll go ahead and open an issue about this in ableC.