return-from-lambda viewed as dangerous, good alternatives

[Neal Gafter]

On Thu, Jan 7, 2010 at 2:12 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
> 2010/1/7 John Rose <John.Rose at sun.com>:
> These points are all good and valid, but I hope that Mark's decision
> has closed the debate on this.

Perhaps we should close all discussion and just wait for Sun to
announce what they're doing?  Or do you think it's appropriate to have
community involvement in the discussion?

> Now, other languages, old (Smalltalk) and new (Scala) do manage to
> have transparent closures. But this is as part of the holistic vision
> for their language. Java's vision is different, and the approaches
> that look and feel right in Java are different.

This shows an ignorance of the history of Smalltalk.  Transparency was
added to Smalltalk later.

>> First, if we were going to do "transparent lambdas" (which I understand we're not, but stay with me a second), adding a new meaning to the "return" keyword obviously interferes with the old meaning, which is "find the enclosing method and return a value from it".  You can test this interference by imagining a hapless programmer refactoring code and pasting some stuff containing a "return" statement into a new lambda expression.
>
> The primary set of users of Project Lambda are those moving up from
> Java 6. They will know about inner classes (where return is local).
> Their primary set of refactoring on receiving JDK 7 will be conversion
> of one method inner classes to lambdas. This refactoring would be
> broken by non-local returns.

The transition to SE 7 is transitory, so any benefits during that
transition are by definition of transitory value.  The language
features introduced during that transition, however, are hopefully
permanent, so the primary driver should be the wholistic design of the
language after the transition.  In other words, we should minimize
artifacts of the language that arise because the the transition
effects.

In this particular case, I don't think it is as important to maximize
the opportunities to unwisely refactor inner classes to closures by
people who are unfamiliar with the new language construct as it is to
support effective use of the language after the transition is complete
by people who are familiar with the new language construct.

Having said that, I believe CfJ 0.6 a&b <http://www.javac.info>
illustrate that there is not necessarily a conflict between the two
goals, as they can be achieved concurrently.

>> Putting a different sub-language with different rules in lambda bodies would make lambdas too dangerous to use.  Imagine again the hapless programmer editing code in and out of lambda bodies.  So we give ourselves permission to bend but not break the principle of transparency.
>
> With respect, I believe you have a mental model of lambdas that is
> correct and pure (transparent wrappers around code that allow it to
> move). Unfortunately, that isn't the mental model that current Java
> developers have for a feature like this, nor is it one that fits the
> (hand-waving) Java-style (evidenced by other languages approach to the
> same problem space). ie. developers know and understand that there are
> different rules for code within a single method.

One the language feature is defined, I think it is reasonable to
believe that programmers will learn it and attempt to build a mental
model around what the language actually provides, rather than trying
to build a mental model around what they think closures might have
been defined as.  That may be difficult to see given that we are in
the process of considering the alternatives, but once things are
settled I think it is reasonable that programmers will bother to learn
something about the construct as it is actually defined before using
it.

>> There's a second reason for not overloading returns, too.  An overloaded return not only fails to implement transparency, but it also PREVENTS any future version of Java (or any sister language) from increasing the transparency to include control transfers.  To overload "return" is effectively to say "we'll never need uplevel branches in Java".  And that is, to put it mildly, short-sighted.  If you've ever designed a multiple-purpose language before, you know that any statement beginning "our users will never need..." is almost always false.
>
> True, if you're designing a new language. Java isn't a new language,
> its an established, but evolving, one. What already exists in the
> language narrows our choices greatly.

Java SE 7 will be a new language, based on but upward compatible with
SE 6.  Within that constraint, SE 7 should be wholistically designed.

> I should also note that there are at least three different ways to add
> non-local returns from a Project Lambda type solution.

You appear to be confusing the goal of transparency with elements
required to achieve it.  Your suggestions provide constructs related
to those elements without actually supporting transparency, and
therefore don't meet that goal.