return-from-lambda viewed as dangerous, good alternatives

[Osvaldo Doederlein]

Hi,

In my country there's a popular saying that roughly translates as "don't
enter a big dogs' fight"; but I'll risk my $2c anyway... :)

I think this discussion has several merits, nobody wants a language that
contains syntax ambiguities, overcomplex rules etc.; OTOH I don't want
half-baked lambdas that miss features that would be very useful and not make
the language significantly harder for the average programmer.
(Unfortunately, we can debate to death if certain features are intuitive or
hard for this "average programmer"; but I agree with some comments that
corner cases that rarely happen in the real world are strawmen in this
debate.)

I'm with Joshua on this one. Java programmers have cut their teeth in inner
classes, and closures will be clearly and intuitively learned as "better
inner classes", even if people don't think about the implementation of
closures as methods of synthethic classes or MethodHandles. (Which may not
be always the case, if javac is smart enough to avoid such code generation
when possible -- i.e. your classic, simple control structures a la
Smalltalk's ifTrue:ifFalse: etc., that can often be fully inlined so there's
no new method and any return inside the closure is just a local branch - but
then again, this is all transparent to the user, and we may keep the
simplification of closure==method for didactic purposes.) The behavior of
"return" inside a closure will be absolutely clear. So much in fact, that
the only difficult design decision (from the EoD-for-avg-Joes POV) is
whether to support non-local returns and how; I don't much mind solutions
like "throw return", "long return", "return <label>" or whatever; any of
these will SCREAM in the user's face that the behavior is NOT the one users
are accustomed since JDK 1.1, which is the local return of inner classes.
It's also a reaffirmation that the standard "return" IS the standard, good
ol' behavior from inner classes.

A+
Osvaldo

2010/1/8 Joshua Bloch <jjb at google.com>

> John,
>
> Hi.  Let me say at the outset that though I disagree with you, I'm not
> trying to be disrespectful, and I trust you won't take offense.
>
> On Thu, Jan 7, 2010 at 1:16 AM, John Rose <John.Rose at sun.com> wrote:
> >
> >
> > For the purposes of this list (lambda-dev), I want to make a clear
> argument
> > against overloading the "return" keyword to denote a lambda result value,
> in
> > addition to its denotations in current Java.
>
>
> I don't think anyone is trying to redefine return. In Java return has
> always
> meant "return this value (or no value)" from the invocation of this method.
> I think that must be true whether the method is a lambda or or an ordinary
> method. I just don't see a problem here.
>
> .I also want to suggest a range of alternatives.
> >
>
> Since I don't see a problem, I don't see the need for a range of (complex)
> alternatives.
>
>
> > It's no good saying "Aha, but every lambda body is really a method in the
> > VM, so the meaning of 'return' is unchanged."  That's a category error.
> >  We're designing language here,
>
>
> We're not designing a language, we're extending one, which is a very
> different game. We must not violate our users' preconceptions. I believe
> that Java programmers will expect a return from within a lambda to return
> from the lambda, and I have anecdotal evidence to back it up. I presented
> code snippets to large groups of people and had them guess at what they'd
> do. The great bulk of them simply assumed that a return from within a
> closure would return from the function it defined.
>
> and it's a mistake to mix in implementation considerations and/or assume
> the
> > writer of the code is thinking about such implementation considerations
> when
> > the lambda is being written.
>
>
> I don't think this is an implementation consideration; I think it's
> fundamental. We're considering adding function types to the language, which
> define functions (AKA methods). The return keyword will return from these
> functions. It seems simple to me. I'm not trying to be obtuse or
> disagreeable;I really do think that' the way the great bulk of our users
> (Java programmers) will see this.
>
>            Josh
>
>