Yield considered harmful

[Pavel Minaev]

On Fri, Jul 9, 2010 at 2:49 PM, Lawrence Kesteloot <lk at teamten.com> wrote:
> On Fri, Jul 9, 2010 at 2:18 PM, Alex Blewitt <alex.blewitt at gmail.com> wrote:
>> Furthermore, 'yield' already has an existant meaning in Java:
>
> Additionally, in Python "yield" is used in generators. If we ever want
> those in Java we'll be sad to not have a good keyword for it.
>
>> Even if non-local returns are added at a later stage, there's no reason that that could not use a new syntax and avoid the complications of misusing return now.
>
> That would violate what Neal calls "transparency":
>
> for (String word : words ) {
>    if (word.contains("http")) {
>        return word;
>    }
> }
>
> would be re-written as:
>
> words.forEach() { word ->
>    if (word.contains("http")) {
>        long return word;
>    }
> }

The hypothetical new syntax does not need to apply to "return" - it
can apply to the lambda as a whole. E.g.:

 words.forEach() {# word ->
    if (word.contains("http")) {
        return word;
    }
 }

where # is a placeholder for something that distinguishes this form of
lambda (a "block" in Ruby parlance) from a proper function. The
meaning of "return" in the body of such a lambda is then adjusted, and
"break" and "continue" are permitted.

Such a lambda expression could furthermore have a distinct type, which
could, for example, be used to prevent it from escaping the scope in
which "break" and "continue" are meaningful (by restricting that type
for return values, fields, captured mutable locals etc).

In the following list, that would be a distinct option #4.

> 1. "yield" or similar for local return, "return" for lexical return.
> Has the problems you point out.
> 2. "return" for local return, "long return" for lexical return.
> Violates transparency.
> 3. Naked expression for local return, "return" for lexical return. Has
> some of the problems you point out and is (IMO) awkward-looking in all
> but the simplest examples (like Nathan's in this thread).