Transparency

[Alessio Stalla]

On Tue, Jul 13, 2010 at 2:34 AM, Neal Gafter <neal at gafter.com> wrote:
> On Mon, Jul 12, 2010 at 4:59 PM, Alessio Stalla <alessiostalla at gmail.com>
> wrote:
>>
>> On Thu, Jul 8, 2010 at 1:01 AM, Bob Foster <bobfoster at gmail.com> wrote:
>> > Neal Gafter wrote:
>> >> Most Java developers have not used lambdas in Java.  Those who have
>> >> used
>> >> them in other languages rarely think of them as a method body.
>> >
>> > A tautology followed by an unprovable assertion, but never mind that.
>> >
>> > This discussion suffers a definitional problem: there is no consensus
>> > on what 'lambda' means. Instead, some people are pushing lambda as in
>> > lisp, others are trying to redefine lambda to be Smalltalk blocks or
>> > lambda as in ad hoc feature in some language that happens to call the
>> > feature lambda.
>> >
>> > I will just state for the record that I have used lambda in other
>> > languages and I think of them as anonymous functions. I truly doubt
>> > that puts me in the 'rarely' category. But let's put it on the table
>> > and stop jawboning about what return means. What does lambda mean?
>>
>> I think your question is very appropriate, also given Neal Gafter's
>> last reply to the "Transparency" thread (liberally quoting: "There are
>> numerous advantages to designing lambda expressions that are
>> transparent").
>>
>> The term "lambda" comes from functional languages and in particular
>> from prof. McCarthy's LISP, which borrowed it from lambda calculus. In
>> that context, "lambda" simply means "anonymous function" - whatever a
>> function exactly is in the language being considered.
>>
>> Now, Java has no functions. Instead, it has methods. Methods are not
>> first-class objects; however, SAM types can be used to simulate
>> first-class methods. We can say that in Java an instance of a SAM
>> class is the closest equivalent to a first-class function object as
>> found in typical functional languages. We can also say that in a sense
>> Java already has both named and unnamed "functions", since "unnamed"
>> classes extending a SAM type can be declared.
>>
>> Keeping that in mind, it is just natural that many people - myself
>> included - when hearing "lambda" and "Java" together first think about
>> simpler syntax for anonymous "functions", i.e. for anonymous inner
>> classes which extend a SAM class.
>> Then naturally people will associate "lambda" more generically with
>> first-class functions as found in the languages they know; for
>> example, people coming from Lisp will expect functions (and thus
>> lambdas) to be full lexical closures. However, strictly speaking that
>> goes beyond the concept of lambda, which is simply that of an
>> anonymous function - again, whatever "function" concretely means.
>>
>> Neal's concept of "lambda" does not appear to me to resemble the
>> concept of "function" but that of first-class code block instead. The
>> key difference being that functions are safe to pass around and call,
>> while code blocks can only safely be called in a certain context, or
>> control transfer will fail. Corollary differences are return vs yield,
>> and yes or no to long control transfer using break/continue/return,
>> which are related.
>>
>> Morale: without stating clearly what "lambda" is supposed to mean,
>> further discussion is not very useful. I propose to use either the
>> expression "anonymous function" or "code block" to avoid confusion.
>
> I'm not sure either captures what you intend.  Methods that return void or
> that have side-effects are not usually termed "functions".

They're not functions in the mathematical sense, but they're functions
as they are commonly named in functional programming languages. Call
them procedures or subroutines if you like.

> Excluding the possibility of failure in a language that has failure (exceptions) as a
> first-class concept is not constructive.

I'm not proposing that.

> 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.

> 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. 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). Languages in the ML family also
don't have long return, at least not by default.

> You allude to the proverbial correspondence between objects (as a collection
> of lambdas closed over each other) and lambdas (as objects with one member)
> to suggest that lambdas should be thought as the method of an object with
> one member.  But it is not possible to have an object in Java with just one
> member.  Lambdas are the simpler of the two concepts due to the purely
> lexical scoping.

No, I didn't mean to allude to that. I meant that SAM types are
commonly used to simulate first-class functions, not that they are
proper closures.

> 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). 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. 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. Mixing
the two unnecessarily complicates the language. This, I think, is the
root of the problem.

Best,
Alessio