Yield considered harmful
Lawrence Kesteloot
lk at teamten.com
Fri Jul 9 14:49:25 PDT 2010
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;
}
}
To use your phrase, we have to re-write the "return" for "long return"
for no practically obvious reason.
Broadly speaking it seems like we have at least three options:
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).
Given these trade-offs, I feel like option 2 is best, possibly even to
the point of having "long continue" and "long break" later.
Well, to be honest, my actual preference is to use CICE as-is for
project lambda, which makes it very clear that "return" should be
local since it looks like a function definition (the name of the SAM
and parentheses). Later if we introduce blocks, we can treat those
very differently because they won't look anything like a function --
they'll look more like a block and a plain "return" there can be
lexical. But it seems like the desire to remove the SAM name from
lambdas is too strong and we're forced into a situation which will
certainly be confusing to programmers down the line, whatever we
choose now.
Lawrence
More information about the lambda-dev
mailing list