Optional brackets around lambda expression

[Rémi Forax]

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:
>>>
>>> #a,b,c->body
>> 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,
>> but...
>>
>> This would be no problem for a PEG. Isn't the whole idea that you can't look
>> ahead a bit somewhat outmoded?
>>
>> Bob
>>
> 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.
>
> Maurizio

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.

Rémi