Transparency

[Neal Gafter]

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".  Excluding the
possibility of failure in a language that has failure (exceptions) as a
first-class concept is not constructive.  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.  Many languages that have
"functions" that can nest, side-effects, and acknowledge failure also have
transparent "return" (lisp, smalltalk, scala, etc).

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.

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.