Reified Lambda Functions

[Howard Lovatt]

Hi Maurizio,

Comments inline below. I have added section numbers to my weblog to make it
easier to refer to sections. The sections in the comments below are the
sections from the weblog. I also added a clarifying comment for mixed
generic and primitive lambdas (in section 5.1).

2010/1/7 Maurizio Cimadamore <Maurizio.Cimadamore at sun.com>

> Howard Lovatt wrote:
>
>> I have posted a *more* formal proposal for reifying lambdas (as suggested
>> by
>> Neal Gafter):
>>
>> http://www.artima.com/weblogs/viewpost.jsp?thread=278567
>>
>> This could be read in conjunction with the original informal proposal:
>>
>> http://www.artima.com/weblogs/viewpost.jsp?thread=277879
>>
>> Which is an easier read :)
>>
>>  -- Howard.
>>
>> 2010/1/3 Neal Gafter <neal at gafter.com>
>>
>>
>>
> Hi Howard
> Wouldn't be more elegant to re-use one of the many existing approach to
> tackle reification and then restrict it so that only function types are
> reified?
>

That could well be a good solution or alternatively generics could be
reified as well. My proposal is simpler than NextGen (because it is
restricted to lambdas). The NextGen compiler would have to be expanded to
include contravariant-overriding (sections 4.3 & 5.3).

>
> The classloader solution you are proposing is very similar to the solution
> proposed by the author of NextGen[1] (a reified Java compiler) - there are
> some disadvantages with that approach:
>
> 1) Creates one classfile per generic instantiation - since you are using a
> modified classloader you can probably avoid generating a classfile and
> synthesize it on the fly - nevertheless the solution will result in
> increased static footprint.
>

Yes it would increase the static footprint, that is a trade of (performance
and integration against footprint). The footprint is minimized by reusing
lambda classes that have the same type. John Rose has also
proposed Anonymous Classes to address this problem.

>
> 2) Heterogeneous (one class per instantiation, as in C++) approaches for
> handling reification have proven to be relatively weak when it comes to deal
> with generic methods - this might not be a problem since your goal is to
> reify lambdas only which corresponds to classes.
>

Generics are untouched and the reified lambdas inherit from generic lambdas
so the two interoperate. This is much the same point as above about
footprint (see above).

>
> A bunch of additional problems that I see in your approach:
>
> - your proposal does not fully reify lamdas; #(x:List<Integer>) and
> #(x:List<String>) will still be identical types
>

No once you use generics then you get erased lambdas, not much you can do
about this without reifying generics. Your example doesn't quite use the
proposed syntax; if I rewrite your example as:

#int(List<Integer>) lam = #int(List<Integer> x) (x.hashCode());

Noting that one of the lambdas types is generic, therefore generic
expansions are used, then section 5.2.1 applies to the LHS and section 5.1
to the RHS and the translation is:

$Callable$1<? extends Integer, ? super List<Integer>> lam = new
$Callable$1<Integer, List<Integer>>() {
  @Overload public final Integer call(List<Integer> x) { return
x.hashCode(); }
}

Which would mean that  the equivalent String example you gave would erase to
the same type, $Callable$1. This is a problem with erasure - the solution is
to reify generics.

>
> - you need to take into account type-variables; #(x:T) - reification in
> this case is much more complex as the concrete type of T will depend on the
> generic instantiation of the context in which the lambda is defined.
>

I think the proposal does do this, see above example. Once generics are used
the types are erased, not much you can do about that. It will however
un-erase a reified lambda that gets treated as a generic, see section 5.3.1.
See first weblog (http://www.artima.com/weblogs/viewpost.jsp?thread=277879)
for an example of this - specifically "#int() i = lI.get(0)" in the section
"Difficult Cases".

>
> [1] - http://www.cs.rice.edu/~javaplt/nextgen/
>
> Maurizio


Thanks for your response,

 -- Howard.


>
>
>
>
>
>
>  On Sun, Jan 3, 2010 at 3:04 PM, Howard Lovatt <howard.lovatt at iee.org
>>> >wrote:
>>>
>>>
>>>
>>>> I have updated the post to cover your example; thanks it is another
>>>> difficult case that needs to be addressed. The updated  blog is at
>>>>
>>>>
>>>> http://www.artima.com/forums/flat.jsp?forum=106&thread=277879&start=0&msRange=15
>>>> .
>>>> I have included a list example like the one you gave. For comparing
>>>> lambda's
>>>> you need to use equals not ==.
>>>>
>>>> Keep the difficult cases coming there may be more subtile bugs in the
>>>> proposal that these examples will tease out.
>>>>
>>>>
>>>>
>>> It isn't clear how to generalize your particular examples into rules for
>>> handling all examples.  While the examples are helpful, they don't really
>>> provide much confidence in the concepts without those underlying rules.
>>>  Can
>>> you please try to formulate your proposal into a set of more generic
>>> rules
>>> for handling all cases?  Trying to formalize the rules would also help us
>>> (and you) to understand if and where rules might be missing.
>>>
>>>
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security System.
>>> For more information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email______________________________________________________________________
>



-- 
 -- Howard.