neal at gafter.com
Tue Jul 13 08:23:12 PDT 2010
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
> > 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
> > 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
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).
More information about the lambda-dev