return-from-lambda viewed as dangerous, good alternatives

[Neal Gafter]

On Thu, Jan 7, 2010 at 4:13 PM, Jonathan Gibbons
<Jonathan.Gibbons at sun.com>wrote:

> I don't have specific syntax in mind. I just have a sense that
> closures/lambdas are functions and within those functions, return should
> have its "obvious" meaning of "return from the function", whereas control
> abstraction is a potential new language feature that allows the user to
> create a limited set of new statement forms without having to wait for the
> next version of Java.  Within these statement forms, return should have its
> "obvious" meaning of "return from the enclosing method".  So, at some level,
> this is just naming.   I think of closures as what I believe you call
> "non-transparent closures", and I think of "control abstraction" or "new
> statement forms" or whatever the right name is as what you are calling
> "transparent closures".   I think the two are different enough to have
> significantly different names, and to be treated separately, even though one
> may be built on top of the other.
>

To me, control abstraction is an informal term describing the kind of
functionality provided by some APIs, in which some "controlled" bodies of
code have their execution deferred, under control of the API.  This deferred
code may have parameters and return values (i.e. "function"), must be
transparent, is typically anonymous, and is defined using some
language-provided abstraction mechanism.  That sounds to me like the
definition of closures <
http://gafter.blogspot.com/2007/01/definition-of-closures.html>, AKA
lambda.  That's why this discussion is taking place in the context of
project lambda.  The control invocation statement form of BGGA, which makes
some such APIs have an apparance similar to built-in forms, is just a nice
sugar on top of that; it is not what makes BGGA support control
abstraction.  I consider the control invocation statement form less
important than being able to use the general underlying primitives.