Syntax decision

[Maurizio Cimadamore]

On 28/09/11 16:24, Henri Gerrits 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;
Note that a Ruby-like syntax using '|' as parameters delimiter is 
probably not gonna fly should we add support for union types (as the 
current prototype does):

|List<A|B>|-> ...

makes it very awkward to read.

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