Syntax decision

[Howard Lovatt]

Brian,

Can the -> be treated like a + operator and have different precedence for
unary and binary forms, i.e. binary form has precedence between ternary and
assignment and the unary form between cast and prefix unary (both forms
binding right to left)? Then:

(T) -> x

Would be an error, like (Integer)+i is. You would need to write:

(T)(-> x)

Again, like you would write (Integer)(+i).

Similarly to +, both:

(x) -> x + 1

and:

x -> x + 1

Would be legal.

 -- Howard.

On 29 September 2011 00:39, Brian Goetz <brian.goetz at oracle.com> wrote:

> Yes, wunderbars were considered and (overwhelmingly) rejected by the EG.
>
> On 9/28/2011 5:27 AM, Lieven Lemiengre wrote:
> > Other languages (such as Scala or Groovy) don't have this problem
> > because they support some placeholder syntax.
> >
> > In reality you don't write "x => x.age <= 0;"
> > But this is very common "someList.partition(x => x.age <= 18)" and I
> > agree this looks bad. Other languages make this clearer using
> > placeholder syntax "someList.partition(_.age <= 18)" or
> > "someList.partition(it.age <= 18)"
> > I hope you are considering something like this, these little closures
> > will be used a lot!
> > (And I don't think replacing '=>' with '->' will help a lot)
> >
> >
> > On Tue, Sep 27, 2011 at 9:18 PM, 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.