Syntax decision

[Henri Gerrits]

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) '|'.
 
Henri


----- Original Message -----
> From: Brian Goetz <brian.goetz at oracle.com>
> To: Howard Lovatt <howard.lovatt at gmail.com>
> Cc: "lambda-dev at openjdk.java.net" <lambda-dev at openjdk.java.net>
> Sent: Wednesday, September 28, 2011 10:41 AM
> Subject: Re: Syntax decision
> 
>T he nilary syntax is still a thorn.  But the obvious solution outlined 
> below -- allow elision of the () -- leads to a syntactic ambiguity.  If 
> -> { statement; } were a valid lambda, then is:
> 
>   (identifier) -> { statement; }
> 
> a one-arg lambda with inferred type, or a cast of a nilary lambda?
> 
> If people have brilliant other suggestions for nilary lambda syntax, 
> we'd consider it.
> 
> 
> 
> On 9/28/2011 2:03 AM, Howard Lovatt wrote:
>> Personally I am glad you have decided to go with -> since I have had
>> trouble reading Scala code, however this is not my main point in this
>> post which is have you decided if you require () for no arguments or if
>> you plan to allow a 'naked' -> e.g.:
>> 
>> shortCutAnd( -> size >= 0, -> size < max ); // Example 
> equivalent
>> to size >= 0 && size < max, but user written
>> 
>> On 28 September 2011 05:18, Brian Goetz <brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com>> wrote:
>> 
>>     Update on syntax: the EG has chosen to stick with the -> form of the
>>     arrow that the prototype currently uses, rather than adopt the =>.
>> 
>>     You could think of this in two ways (I'm sure I'll hear both):
>> 
>>       - This is much better, as it avoids some really bad interactions with
>>     existing operators, such as:
>> 
>>         x => x.age <= 0;                // duelling arrows
>>     or
>>         Predicate p = x => x.size == 0;  // duelling equals
>> 
>>       - What a bunch of idiots we are, in that we claimed the goal of doing
>>     what other languages did, and then made gratuitous changes "just 
> for the
>>     sake of doing something different".
>> 
>>     Obviously we don't think we're idiots, but everyone can have an
>>     opinion :)
>> 
>>     In the end, this was viewed as a small tweak to avoid some undesirable
>>     interactions, while preserving the overall goal of "mostly looks 
> like
>>     what lambdas look like in other similar languages."
>> 
>> 
>> 
>>     On 9/8/2011 4:07 PM, Brian Goetz wrote:
>>       > This just in: the EG has (mostly) made a decision on syntax.
>>       >
>>       > After considering a number of alternatives, we decided to 
> essentially
>>       > adopt the C# syntax.  We may still deliberate further on the fine
>>     points
>>       > (e.g., thin arrow vs fat arrow, special nilary form, etc), and
>>     have not
>>       > yet come to a decision on method reference syntax.
>>       >
>>       > The C# syntax is:
>>       >
>>       >    lambda = ArgList Arrow Body
>>       >    ArgList = Identifier
>>       >              | "(" Identifier [ "," 
> Identifier ]* ")"
>>       >              | "(" Type Identifier [ "," Type 
> Identifier ]* ")"
>>       >    Body = Expression
>>       >              | "{" [ Statement ";" ]+ 
> "}"
>>       >
>>       > Here are some examples of lambda expressions using this syntax:
>>       >
>>       >    x =>  x + 1
>>       >    (x) =>  x + 1
>>       >    (int x) =>  x + 1
>>       >    (int x, int y) =>  x + y
>>       >    (x, y) =>  x + y
>>       >    (x, y) =>  { System.out.printf("%d + %d = %d%n", 
> x, y, x+y); }
>>       >    () =>  { System.out.println("I am a Runnable"); }
>>       >
>>       > The decision to choose this syntax was twofold:
>>       >    - The syntax scores "pretty well" on most subjective 
> measures
>>     (though
>>       > has cases where it looks bad, just like all the others do).  In
>>       > particular, it does well with "small" lambdas that are 
> used as method
>>       > arguments (a common case), and also does well with large
>>       > (multi-statement) lambdas.
>>       >
>>       >    - Despite extensive searching, there was no clear winner among 
> the
>>       > alternatives (each form had some good aspects and some really not
>>     very
>>       > good aspects, and there was no form that was clearly better than 
> the
>>       > others).  So, we felt that it was better to choose something that 
> has
>>       > already been shown to work well in the two languages that are
>>     most like
>>       > Java -- C# and Scala -- rather than to invent something new.
>>       >
>>       > A compiler implementation should be available soon.
>>       >
>>       >
>>       >
>> 
>> 
>> 
>> 
>> --
>>     -- Howard.
>> 
>