Syntax decision

[Ali Ebrahimi]

Hi,
my intend for low is low rate not low priority.



On Wed, Sep 28, 2011 at 7:08 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> The need for disambiguation in overload resolution is very important. Don't
> write that off as being of "low" priority.
>
>
> On 9/28/2011 10:58 AM, 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.
>>
>> Best Regards.
>>
>> On Wed, Sep 28, 2011 at 6:11 PM, Brian Goetz <brian.goetz at oracle.com
>> <mailto: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**>
>>     > <mailto: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.
>>     >
>>
>>
>>