Optional brackets around lambda expression
forax at univ-mlv.fr
Fri Jun 17 03:14:36 PDT 2011
On 06/17/2011 10:57 AM, Maurizio Cimadamore wrote:
> On 17/06/11 09:49, Bob Foster wrote:
>> Maurizio Cimadamore wrote:
>>> On 17/06/11 07:59, Reinier Zwitserloot wrote:
>>>> Er, right. This redmond variant syntax of Ali Ebrahimi:
>>>> a, b, c -> expression
>>>> cannot work, as far as I can tell, in the current parser architecture of
>>>> javac and ecj, and attempting to work around it or fix the parser is a
>>>> massive undertaking. I think - experts, please chime in!
>>> This is right - you can remove the parenthesis around the args when
>>> there is just one argument (and there is no explicit type on the lambda
>>> parameter); in that case the grammar would be something like:
>>> IDENTIFIER '->' ...
>>> In all other cases you need enclosing parens, as in:
>>> (a,b,c) -> body
>>> (Type1 a, Type2 b)-> body
>>> [the above can be disambiguated from a cast or a parenthesized
>>> expression because of the trailing ')->' sequence, which would be unique
>>> to lambdas].
>>> Another alternative, for those who don't like surrounding parenthesis,
>>> would be to use a special prefix (as in SoTL or Strawman), as in:
>> I'm not going to pretend to be a parsing expert, particularly if it's
>> defined in terms of the changes can be easily made to the the javac parser,
>> This would be no problem for a PEG. Isn't the whole idea that you can't look
>> ahead a bit somewhat outmoded?
> Of course you can lookahead; but certain expressions, as pointed out
> will remain ambiguous:
> process(x, y, z, a, b, c, d -> a);
> Which means the parser will have to choose one for you.
Foo foo = #a,b,c->body
is ambiguous too
because #a can be a method reference and the following comma
the comma of the initializer.
More information about the lambda-dev