Syntax decision

[Brian Goetz]

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.
>
>
>