Optional brackets around lambda expression

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Fri Jun 17 01:57:29 PDT 2011


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


More information about the lambda-dev mailing list