Syntax decision
Brian Goetz
brian.goetz at oracle.com
Wed Sep 28 08:38:12 PDT 2011
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.
> >
>
>
More information about the lambda-dev
mailing list