Transparency

[Paul Benedict]

If I may ask a broad question... Since Neal provided a working
prototype of Closures, why did OpenJDK 7 not begin its coding efforts
from his work? Being a side-line judge here (excuse the metaphor), it
appears his prototype already solves some of the questions being
discussed, and there were enough open issues for healthy community
feedback. Wouldn't it be wise to start from something -- augmenting
and disassemble as you please -- rather than code the official
solution from square one?

On Tue, Jul 13, 2010 at 10:23 AM, Neal Gafter <neal at gafter.com> wrote:
> 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).
>
>