Project Lambda: Java Language Specification draft

[Neal Gafter]

On Fri, Jan 22, 2010 at 5:36 PM, Neal Gafter <neal at gafter.com> wrote:
> On Fri, Jan 22, 2010 at 2:55 PM, Alex Buckley <Alex.Buckley at sun.com> wrote:
>> The type of this in a lambda expression is the function type of the
>> lambda expression.
>
> Oh, really?  So the result type of a lambda expression can depend on
> the type of "this" (if "this" appears within a return statement).  And
> the type of "this" depends on the result type of the lambda
> expression.  Your specification gives no hint how this infinite
> regress is to be resolved.

Lest you think this is a non-issue, here are two ways of looking at it:

The compiler needs to analyze the body of the lambda expression to
know the type of the lambda expression, because it has to know the
types of all of its return statements.  On the other hand, the
compiler needs to know the type of the lambda expression before it can
analyze the body, because the type of "this" may be used in the body
and needs to participate in that analysis.  Therefore, the compilation
strategy for lambdas must be much more sophisticated than the usual
type analysis done by a Java compiler.

Consider the following program that purportedly prints the factorial of 15:

System.out.println(#(int x)(x <= 1 ? 1 : x*this!(x-1))!(15));

According to the spec, this program computes the factorial of 15
correctly using "double" arithmetic, even though the program doesn't
mention "double" anywhere.

Also, according to the spec this program computes the factorial of 15
incorrectly (the result overflows) using "int" arithmetic.

Without something to distinguish these interpretations of the program
(there are others, too!), the spec itself is ambiguous.