Lambda Conversion Considered Harmful?

[Neal Gafter]

On Fri, Feb 19, 2010 at 2:09 PM, Alex Buckley <Alex.Buckley at sun.com> wrote:

> Neal Gafter wrote:
> > On Fri, Feb 19, 2010 at 11:18 AM, Joshua Bloch <jjb at google.com> wrote:
> >> I don't think so.  The BGGA proposal also uses the lambda conversion to
> >> produce SAM-type (interface only) implementations.
> >
> > Not so.  What BGGA calls the lambda conversion is completely unrelated
> > to what project lambda calls the lambda conversion.  I don't know why
> > project lambda uses that name, by the way, since it converts a
> > function type to a SAM type; lambdas have nothing to do with it.
>
> A conversion in the Java language is a mapping from one type to another
> type.


Not quite.  A mapping associates a distinct element in the codomain with
each value in the domain.  A conversion, on the other hand, is a kind of
binary relation between types.


> BGGA/CfJ describes a mapping from an expression to a type, so I
> don't know why you call it a conversion.
>

The type of a lambda expression in CfJ is not denotable in source, but that
isn't the same as saying that it doesn't have a type.  The type of a lambda
expression in CfJ is defined by the set of declared argument types, result
expressions, and thrown types of the lambda's body.  The lambda conversion
is a binary relation all of whose pairs are the type of a lambda expression
on the left and a SAM interface on the right.

There are other types in the Java language that are not denotable, for
example intersection types (JLS3 4.9), infinite/recursive types (JLS3
15.12.2.7), and int constants whose "value .. is representable in the type
of the variable" (JLS3 5.2).  Those types are used in defining conversions
too.

> BGGA demonstrates that you can do both with one syntax, and without
> > the performance hit of the current draft's lambda conversion.
>
> It is irregular to support "conversion" from only a literal lambda
> expression to a SAM type, rather than from any value of function typre
> to a SAM type.
>

CfJ (and BGGA) doesn't define any conversions from any values of function
type to any other types.  Those conversions are subtype relations already
defined by the JLS.  In CfJ, a function type *is* a SAM type; they are both
handled precisely the same way by the type system and the conversions,
uniformly.  I agree that it would be irregular for you to take this approach
as long as you continue to define lambda expressions to be of function type,
and make that visible in the language through a "this".