Optional brackets around lambda expression

[Maurizio Cimadamore]

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

Maurizio
> This:
>
> process(x, y, z, a, b, c, d);
>
> is hard to differentiate from this:
>
> process(x, y, z, a, b, c, d ->  5);
>
>
> which is analogous to trying to differentiate this:
>
> try ( List<  String>  x = whatever ) {}
>
> from this:
>
> try ( List<  String ) {}
>
>
> these 2 similes share a lot of properties: It's a massive undertaking to fix
> the parser because the two concepts inside the parens are completely
> different, yet both seem easy to differentiate from a 'human brain'
> perspective (and an RD parser would have absolutely no problem with this
> either). Nevertheless, the expression-only form of the ARM block has been
> removed from the ARM spec because of this, and I rather doubt the benefit of
> this syntax over i.e. parens-less strawman is worth the massive headache.
>
>   --Reinier Zwitserloot
>
>
>
> On Fri, Jun 17, 2011 at 1:30 AM, Steven Simpson<ss at comp.lancs.ac.uk>  wrote:
>
>> On 16/06/11 11:19, Ali Ebrahimi wrote:
>>> Hi, how about this one:
>>>
>>> process( x ->  x + 1 );
>>>   process( x ->  { return x + 1; } );
>>>   process(  x ->  {
>>>    if (x == 0) {
>>>      return 0;
>>>    }
>>>    return x + 1;
>>>   });
>> It's arguably more aesthetic.  Is it harder to parse (infix vs prefix)?
>> I imagine not significantly so, but parser writers' opinions surely
>> carry more weight.
>>
>> I think you need some bracketing if there's more than one parameter:
>>
>> process( x, y ->  x + y );
>>
>> You'd have to use more than just the grammar to determine that the first
>> x is not a separate parameter, which would be a Bad Thing, right?  So
>> one of these, or similar, would be necessary:
>>
>> process( (x, y) ->  x + y );
>> process( ( x, y ->  x + y ) );
>> process( { x, y ->  x + y } ); // closest to current syntax?
>>
>> Of those, I'd favour the brackets around just the parameters, based on
>> the same argument that supports "#(params) expr", i.e. low precedence is
>> only a problem for the most contrived cases.  I'd also rather save the
>> braces for statement lambdas.
>>
>> Still thinking of stripping away superfluities, can you get away without
>> '->', provided you have brackets around the parameters?  I think no, as
>> "(x) -x" would be troublesome.
>>
>>