Transparancy

[Neal Gafter]

On Wed, Jul 7, 2010 at 5:48 PM, Joshua Bloch <jjb at google.com> wrote:

> I believe this is an abuse of the word "transparency."  There's nothing
> transparent about making the "return" keyword do double duty to mean "long
> return."  It's a new concept, and if and when it is to be supported in
> Java,
> it deserves a new keyword.
>

"return" currently means return from the nearest enclosing method or
constructor.  It is an existing concept using an existing keyword.  A lambda
expression is a new concept, so yielding a value from a lambda expression is
therefore a new concept.

The idea of transparency is that the boundaries of a lambda expression do
not change the meaning of the program elements within the lambda compared to
what those program elements would mean outside the lambda ("transparent"
because constructs appear unchanged by the boundary of the lambda except
that they are delayed).  The boundaries of the lambda are said to be
"transparent" if this property holds.  There are numerous advantages to
designing lambda expressions that are transparent.  For constructs such as
"return", "break", etc, which are control constructs, this is "control
transparency".  For a longer list of the various kinds of transparency worth
considering, see the bullet list in <
http://gafter.blogspot.com/2007/01/definition-of-closures.html>.

> However, if future transparency is the goal...
>
> When you say "future transparency," I believe that what you mean is
> "allowing lambdas to be used to emulate control constructs in the future."
>  I think you should call it that.
>

That ability is one of the many advantages of designing lambda expressions
to be transparent.  I don't think we should call a design principle by the
name of a single use case that it might (or might not) enable.