Transparency

[Neal Gafter]

On Tue, Jul 13, 2010 at 1:45 AM, Alessio Stalla <alessiostalla at gmail.com>wrote:

> > What you call "code block" would likely be used in most circumstances
> without any contained control-flow
> > constructs.  In other words, you appear to be naming distinct use cases
> > rather than distinct language constructs.
>
> No, because the two "use cases" give the language different semantics.
> With lambdas-as-functions one can copy-paste the body of a method in
> the body of a closure and it will "just work". With lambdas-as-blocks
> that doesn't hold.
>

With lambdas-as-blocks you can just copy-paste a block of code into a lambda
to delay its execution.  With lambdas-as-method-bodies that doesn't hold.

>
> > Many languages that have "functions" that can nest, side-effects, and
> acknowledge failure also have
> > transparent "return" (lisp, smalltalk, scala, etc).
>
> I don't know Smalltalk nor Scala, but Lisp surely has no transparent
> return by default.


Common lisp's "return" will pass transparently though any number of
intervening lambda boundaries.


> You have to tell it explicitly to do a long return
> with (return-from <enclosing-lexical-block-name>), and that's a
> seldom-used feature (but Lisp has macros, making the use of closures
> for control structures unnecessary).


Macros and transparent lambdas are incomparable in expressive power.

Languages in the ML family also
> don't have long return, at least not by default.
>

Not a "local" return.  But you can define a returning construct, which would
then be transparent.


>  > Designing a new language construct to do exactly what you can already do
> is
> > not the best way to increase the flexibility of the language.
> >
> > In any case, my suggested definition appears here:
> > <http://gafter.blogspot.com/2007/01/definition-of-closures.html>.  Feel
> free
> > to substitute "lambda" for "closure" in most of that.  That post also has
> > pointers to a number of papers that explain in more detail the utility of
> > lambdas in the sense defined there.
>
> Lambda and closure are two orthogonal concepts. Lambda means anonymous
> function, where "function" does not necessarily imply "closure".
> Closure means a function that captures the lexical environment it's
> been defined in, and can be named or unnamed (lambda). In that sense,
> lambdas can be mapped to anonymous SAM types in Java, while closures
> cannot (since anonymous inner classes only capture a fraction of their
> outer lexical environment, final local variables).


Lambdas are *capable* of capturing the lexical environment; when they do,
they are closures.  You've found one of many reasons that anonymous inner
classes are neither lambdas nor full closures.

In any case, long
> control transfer by default ihmo contrasts with the concept of
> function altogether, so neither lambda nor closure would be a fitting
> term.


Indeed, a void-returning thing contrasts with the concept of function
altogether as well.


> I'd really keep the two concepts separate; the same object
> cannot be both a function to be mapped over the elements of a
> collection and the body of a user-defined control structure.


Huh?  Why not?  The only difference is whether or not it yields a new value
or not (void result type).