Transparancy

[Brian Goetz]

> Most developers seem to think that a lambda body is comparable to a SAM/AIC implementation body, which is a method.

This is true, but only because they have no other experience.  The reality is 
that they are mostly like method bodies, but not entirely like method bodies. 
  Such first-order approximations are very useful in forming mental models but 
should not be taken too far!

Here are some contexts in Java-like languages where a control flow statement 
stops executing in the current context and resumes in another:

  A Return from a method.
  B Local return from a closure.
  C Lexical return from a closure.
  D Incremental production from a coroutine.
  E Terminal production from a coroutine.
  F Value production from a local block (i.e.:
       var x = { var y = 3; yield 3*y }
  G Lexical return from a local block.

Java currently only has A.  So our thinking about "what return means" is 
heavily conditioned by our experience with A.

BGGA has both B and C.  The current SotL draft has "yield" for B and currently 
nothing for "C".

I think we can all agree that "return" is absurd for "F".  (You might not like 
"yield" because it is used for something else (D/E) in C# and yet something 
else (and weird!) in Ruby, but "yield" is a fine candidate for F.)

So "return" is obviously right for A and obviously wrong for F.  B and C have 
something in common with methods, and something in common with local blocks. 
We're letting the fact that Java has methods and does not have local blocks 
color our thinking that closures are "just like" methods when in fact they are 
"mostly like" methods.  (We can disagree about whether it's 98/2 or 90/10, but 
it's obviously not 100/0.)

Imagine you grew up in a world where the only animals were dogs (methods). 
Your mental model of animal would be heavily influenced by the characteristics 
of dogs -- for example, animals have four legs*.  Then one day ants (local 
blocks) were introduced into your planet.  They are obviously not dogs, but 
they have more legs than you and are shorter than you, so they are more like 
dogs than like humans, so we redefine the world as "there are people and 
animals; animals are dogs and ants."  Having thus classified things, you are 
again comfortable with the world.  Two hundred years later, a cat (closure) 
arrives on your planet.  Most people in this situation will think "what a 
fancy dog!"

The point is that "return" is only obvious for B if you have grown up in the 
world of A-but-not-F.  And if we're sure that C/D/E/F/G will *never* be added 
to Java, then we are perfectly justified in ignoring all the cat-like aspects 
of closures and lump them in with dogs, and choose "return" for B and never 
think about it again.  But if there's any reasonable chance that F (or even C) 
will ever become part of Java, then all of a sudden these dogs that say "meow" 
start to seem really weird.

That said, this forum is for lambda discussions, so this is probably not the 
place for a discussion about which of these forms Java should have (beyond 
A/B/C).  However, considerations of where Java might or might not go in future 
releases that do not even have numbers yet do (and should!) inform our thoughts.




*Yes, everyone has a three-legged dog story.