Lambda and JSR 292 method handle

[Howard Lovatt]

Neal,

Good points, the first:

>

> List<? *extends* #String(Object)>
>


> to a value of type
>

> List<? *extends* #Object(String)>
>



Is easily fixable by having the reified versions extend the generic versions
with a special case for primitives, i.e.:

*public* *abstract* *class* Callable$Int *implements* Callable$0<Integer> {
  *public* *abstract* *int* callInt();
  @Override *public* *final* Integer call() { *return* callInt(); }}



> Also, there need to be subtype relations in both
> directions between your Callable$0<String> and
> Callable$String but that is impossible because they are
> distinct interfaces. If you try to provide the subtype
> relations in just one direction, things quicky get out of
> hand (i.e. an exponential explosion in direct
> superinterfaces of the generated interfaces) when there
> are multiple lambda arguments.

The above modification to implement Callable$... solves this problem in one
direction and the other is via 'cast' methods. The idea was that the 'cast'
methods are loader generated, though re-reading my post I didn't make this
clear (sorry).

I am making the assumption that these 'casts' are rare and therefore in
practice you won't get an explosion of 'cast' methods.

 -- Howard.

2009/12/29 Neal Gafter <neal at gafter.com>

> There are a number of fatal problems with this approach.  The worst is that
> you can't use any explicit code to implement subtype conversions because
> they don't work through generics.  For example, your scheme does not provide
> any way to convert a value of type
>
> *List<? extends #String(Object)>*
>
> to a value of type
>
> *List<? extends #Object(String)>*
>
> This conversion is just as important as the conversion on the underlying
> function types.
>
> Also, there need to be subtype relations in both directions between your *
> Callable$0<String>* and *Callable$String* but that is impossible because
> they are distinct interfaces.  If you try to provide the subtype relations
> in just one direction, things quicky get out of hand (i.e. an exponential
> explosion in direct superinterfaces of the generated interfaces) when there
> are multiple lambda arguments.
>
> Cheers,
> Neal
>
>
> On Tue, Dec 29, 2009 at 2:50 PM, Howard Lovatt <howard.lovatt at iee.org>wrote:
>
>> You could reify lambda's, see:
>>
>> http://www.artima.com/weblogs/viewpost.jsp?thread=277879
>>
>> for details. This would solve many of the erasure 'issues'. But as Neal's
>> example shows, not in all cases.
>>
>> 2009/12/23 Neal Gafter <neal at gafter.com>
>>
>>>  I don't think there is an option to reify function types.  That's
>>> because generics are already non-reified.  In this code
>>>
>>> *<T> #T() constant(T t) {
>>>     return #() t;
>>> }
>>> *
>>>
>>> the returned lambda cannot, in principle, be reified if generics are not
>>> reified.  This is independent of whether function types are mapped to
>>> interfaces, method handles, or something else.  There may be issues with it,
>>> but they aren't "disadvantages" except by comparison to a scheme that does
>>> not have these issues, and no such scheme has been proposed.
>>>
>>>
>>> On Wed, Dec 23, 2009 at 1:06 PM, Howard Lovatt <howard.lovatt at iee.org>wrote:
>>>
>>>>  Presumably the problems with using generic style annotations and
>>>> erasing the
>>>> actual type include:
>>>>
>>>>   1. Can't have two methods of the same name only distinguished by
>>>> lambda
>>>>
>>>>   type, e.g. filter( #boolean(int) ) and filter( #boolean(float) )
>>>>
>>>
>>> These are distinguished in CfJ, but not in a hypothetical erasure to
>>> MethodHandle.
>>>
>>>
>>>>   2. Can't have arrays of lambdas that are type safe, e.g. new #(int)()[
>>>> n
>>>>   ]; // Illegal
>>>>
>>>
>>> Right.
>>>
>>>
>>>>   3. Can't have instanceof tests (this might be possible since type
>>>>
>>>>   information is carried at runtime)
>>>>
>>>
>>> No, type information cannot, in principle, be guaranteed to be available
>>> at runtime unless generics are reified.
>>>
>>>
>>>>   4. Can't have primitive types (this might be fixable with an extension
>>>> to
>>>>   the signature attribute)
>>>>   5. Can't have static fields that are lambdas (this might be fixable
>>>> with
>>>>
>>>>   an extension to the signature attribute)
>>>>
>>>
>>> Right: the signature attributes would be extended to express function
>>> types, addressing these two issues.
>>>
>>>
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security System.
>>> For more information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
>>>
>>
>>
>>
>> --
>>  -- Howard.
>>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
 -- Howard.