A syntax option (function types versus arrays)
jjb at google.com
Tue Mar 2 10:12:12 PST 2010
Ooops, sorry; I thought the last message I answered was your response to my
On Tue, Mar 2, 2010 at 3:41 AM, Peter Levart <peter.levart at marand.si> wrote:
> On Tuesday 02 March 2010 08:58:28 Joshua Bloch wrote:
> > Peter,
> > On Mon, Mar 1, 2010 at 11:49 PM, Peter Levart <peter.levart at marand.si
> > > I think we don't need statement lambdas if we allow expression to be
> > > preceeded by statements (like in block expression of CfJ0.6b):
> > >
> > > Lambda:
> > > '(' FormalParameters_opt '->' Statements_opt Expression ')'
> > >
> > > for void lambdas "void" keyword could be defined as expression of type
> > > void:
> > >
> > > (->void) lambda = (-> System.out.println("Hello!"); void);
> > >
> > Why do you like this better than the current proposal?
> > Josh
> Regarding function types syntax I don't really have a preference to the
> order of (parameter types, return type, throws types) but I think that a
> syntax that composes well (nests) is better. In this regard the current
> proposal is not the best of all alternatives.
I agree that it would be nice if we had something that nests better, and I'm
totally open to suggestion. But this alternative comes with many downsides:
surrounding a type in parens might appear tempting, but it really looks like
a cast to current-day Java programmers. As per my previous e-mail, I'm all
about designing a facility that is maximally readable, familiar, and
non-threatening to current-day Java programmers.
> Regarding preference to expression lambdas, I think they provide a way to
> avoid defining the meaning of "return" at present time. The 1st release of
> lambdas in JDK7 could simply disallow "return". Experience gathered from the
> milions of Java developers in comming years would help shape a decision of
> what to do with "return" (be it local or transparent) for the next release
> in JDK8 which could add statement lambdas as well.
I think you can probably guess how I feel about this argument. I believe
that preserving the meaning of return to return a value from the
function-object invocation (as per current-day use of SAM types) is the way
to go. If, in a future release we elect support non-local returns, it will
probably require a new keyword to clearly distinguish local and non-local
returns. We should cross that bridge when/if we come to it, but in the
meantime, it's our job to make the best possible lambda syntax and
semantics, as per the charter of this project.
More information about the lambda-dev