lambda or reified lambda

[Neal Gafter]

On Wed, Nov 18, 2009 at 1:37 PM, Rémi Forax <forax at univ-mlv.fr> wrote:

> Hi Neal,
> I've just read your new proposal for lambda in Java (v0.6a).
>
> A small remarks, I think that defined @Shared as an annotation
> is not necessary. 'shared' as a local keyword should be better.
>

Since it only suppresses a warning, even a context-sensitive keyword seems
overkill.


> Your proposal doesn't say that function types are not reified:
>

The proposal defines function types as instances of generic interfaces.  If
interfaces are not reified, then it follows logically that function types
are not reified and therefore need not be specified.


>   #int(String) fun = #(String text) text.length();
>   #int(Object) fun2 = fun; // ok, subtyping
>
>   #int(String) fun3 = (#int(String))fun2; // unsafe warning.
>
> What is the reason to not use method handle to implement lambdas ?
> You will get reification for free.
>

On the contrary, there are many issues preventing that.  Here are two
examples:

First, method handles do not have VM-verified contravariance of argument
types and covariance of return types.  Consequently, they cannot support
function subtyping.  For example, if it requires code to convert an
#int(Object) into an #int(String) and the result of the conversion is not
reference-equal to the original value, then how would the compiler generate
code to convert an Iterable<#int(Object)> into an Iterable<#int(String)>?

Second, lambdas inside generic methods cannot in principle be reified if
generic methods are not reified:
*
*
*<T> #T() makeClosure(T t)*
*{*
*  return #()t; // what is the reified type of the closure here?*
*}*

Cheers,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091118/67b5d204/attachment.html