Syntax decision

[Maurizio Cimadamore]

On 28/09/11 15:58, Ali Ebrahimi wrote:
> Hi,
> I think with great support for type inference the need for casting lambas
> (unless for disambiguating overloaded methods,... ) would be low.
> And this ambiguity can be solved by applying some precedence in favor of
> lambdas or versa.
But, if you have something like:

m((T)-> { ... });

and you want it to be a nilary lambda converted to some target type T, 
how do you do that? If you exploit precedence as per your suggestion, 
this will always be a one-ary lambda.

Of course, one way out would be to disambiguate using '()', as in:

m((T)()-> { ... });

Is the cure worse than the disease? I guess it depends on the frequency 
of nilary lambdas and how often do you need an explicit target type (as 
you pointed out, this is closely related to how well inference performs).

Maurizio
> Best Regards.
>
> On Wed, Sep 28, 2011 at 6:11 PM, Brian Goetz<brian.goetz at oracle.com>  wrote:
>
>> The 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.
>>>
>>