Syntax decision

[Paigan Jadoth]

What about:

1.) one-arg lambda with inferred type:
(identifier) -> { statement; }

2.) really wanting to cast a nilary "-> { statement; }" lambda:
(type) (-> { statement; })

This is similar (familiar, regular, consistent, if you will) to already
additional required parens for casts like
((type)identifier).method()

Even if it ends up being
((type) (-> { statement; }))
it's (in my humble developer opinion) still better to have this and an
uncluttered short "->{...}" nilary lambdas than always having those dangling
empty parens "()->[...}" and a slightly nicer cast-construct.

I may also add that since properly applying generics everywhere where
reasonable, I hardly write any cast anymore. Only for polymorphic stuff like
reflection where really only Object is returned API-wise.
So I dare to say that given todays's already existing Java syntax
capabilities, future nice nilary lambdas are more important that future
little-bit-nicer-casts-for-nilary-lambdas.


I gladly admit that I'm no compiler expert, so I may miss important stuff,
of course :).


Oh on a side note on the original post:
I find the "->" much better than "=>". If arrowlings at all instead of the
more regular "#(){...}" pattern, then something definitely distinct from the
gte/lte tokens is clearly better. And "because the others do that" has never
been a good argument, anyway :D.
I also think the EG did right to refuse those "_" and "it" magic tokens, I
find those Scala sample codes containing them absolutely horrible to read.
Scala very much is one of those hype languages that are only "easy" once you
have memorized and internalized it's extremely weird syntax character. Noone
can tell me that "def sum(l: List[int]): int = (0/:l){_+_}" is anything even
remotely near to expressive, concise, readable. Please never add such
trickery to Java. As they say, reading is more important that writing ...
ultra compressed hacker-geek code.
Btw: Are they really called "wunderbar"? That's German for "wonderful" :DD


On Wed, Sep 28, 2011 at 4:41 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.
> >
>
>