Syntax decision

[Henri Gerrits]

I meant "doesn't"

 
----- Original Message -----
> From: Henri Gerrits <henrigerrits at yahoo.com>
> To: Stephen Colebourne <scolebourne at joda.org>; lambda-dev <lambda-dev at openjdk.java.net>
> Cc: 
> Sent: Wednesday, September 28, 2011 11:57 AM
> Subject: Re: Syntax decision
> 
> Of course there is also the bitwise OR operator to consider.
> I think the parser's lookahead should be able to handle these potential 
> syntactical complications.
> 
> But do you really NEED a no-arg placeholder?
> 
> BTW: the C# syntax posted by Brian originally does seem to allow the 
> '()' syntax either:
> 
>>       > The C# syntax is:
>>       >
>>       >    lambda = ArgList Arrow Body
>>       >    ArgList = Identifier
>>       >              | "(" Identifier [ "," 
> Identifier ]* ")"
>>       >              | "(" Type Identifier [ "," Type 
> Identifier ]* ")"
>>       >    Body = Expression
>>       >              | "{" [ Statement ";" ]+ 
> "}"
> 
> I must add I'm new to this discussion.
> 
> Henri
> 
> ----- Original Message -----
>> From: Stephen Colebourne <scolebourne at joda.org>
>> To: lambda-dev <lambda-dev at openjdk.java.net>
>> Cc: 
>> Sent: Wednesday, September 28, 2011 11:32 AM
>> Subject: Re: Syntax decision
>> 
>> On 28 September 2011 16:24, Henri Gerrits <henrigerrits at yahoo.com> 
> wrote:
>>> Since the cast syntax can't be touched, one way out could be to 
> change 
>> the arg delimiters for the lambda, e.g.;
>>> 
>>> |x, y| -> x + y;
>>> 
>>> Personally, I find this a bit more readable when the lambda is 
> provided as 
>> an argument to a method or constructor:
>>> 
>>> c.sort(|x, y| -> x > y);
>>> 
>>> instead of:
>>> 
>>> c.sort((x, y) -> x > y);
>>> 
>>> But I'm sure you will already have considered (and rejected) 
>> '|'.
>> 
>> Since  the decision is to go away from familiar things in Java (as
>> opposed to #() {stmt}), I might also favour:
>>   |x, y| -> x + y
>> 
>> It is a lot clearer in many ways in complicated situations, and would
>> be beter for the eye in finding the target of "return" 
> statements.
>> 
>> I don't know without looking closer whether this is sufficiently
>> distinguishable from OR however:
>>   || -> expr
>> 
>> Stephen
>> 
>