Typed Method handles

[Brian Goetz]

For better or worse, the VM type system and the language type system are 
not the same (and the gap between them is monotonically increasing). 
The VM doesn't know anything about subtyping, covariant overrides, 
generics, wildcards, return-type-substitutability, subsignatures, boxing 
conversions*, widening conversions, etc.  Method handles are a VM-level 
construct for representing VM-level methods using the VM type system. 
It is best if we don't burden them with too much baggage from another 
type system; that will only slow them down and make them disappointing 
to both VM and language users.

What you want to do makes sense in a world with reified types (where the 
VM and language type systems match up) -- tying together the 
language-level notion of function with the VM-level notion of function 
is natural and powerful and good (and has in fact been discussed on the 
292 EG, among other places).  But we are already familiar with the pain 
of trying to paper over the differences between the two type systems, 
and while erased function types may seem better than nothing now, so did 
erased generics way back when...

IF the language had function types then it would be a no-brainer for 
MethodHandle to be generic in the function type: MethodHandle<F> where F 
is a function type.  We rejected function types because erased function 
types were so lame.  If we can have reified function types in the 
future, then this will be an obvious place to backfill this association.


*OK, method handles can deal with this one.

On 6/9/2011 10:59 AM, Rémi Forax wrote:
> On 06/09/2011 04:46 PM, Ali Ebrahimi wrote:
>> Hi Remi,
>>
>> On Thu, Jun 9, 2011 at 5:59 PM, Rémi Forax<forax at univ-mlv.fr
>> <mailto:forax at univ-mlv.fr>>  wrote:
>>
>>      On 06/09/2011 04:11 PM, Ali Ebrahimi wrote:
>>      >  Hi Remi,
>>      >
>>      >
>>      >  On Thu, Jun 9, 2011 at 4:49 PM, Rémi Forax<forax at univ-mlv.fr
>>      <mailto:forax at univ-mlv.fr>>   wrote:
>>      >
>>      >>    On 06/09/2011 12:33 PM, Ali Ebrahimi wrote:
>>      >>
>>      >>  Hi Remi,
>>      >>  comments inlined.
>>      >>
>>      >>  On Thu, Jun 9, 2011 at 1:49 PM, Rémi Forax<forax at univ-mlv.fr
>>      <mailto:forax at univ-mlv.fr>>   wrote:
>>      >>
>>      >>>  On 06/09/2011 11:55 AM, Ali Ebrahimi wrote:
>>      >>>>  Hi all,
>>      >>>>  What happens if method handles takes variable arty of generic
>>      type
>>      >>>>  parameters.
>>      >>>>
>>      >>>>  MethodHandle<void,int>    mh = #{x ->    System.out.println(x);};
>>      >>>>
>>      >>>>  mh.invokeExack(1); //compiles
>>      >>>>
>>      >>>>  mh.invokeExack("1"); //compile fail
>>      >>>    I've proposed this syntax last year or before.
>>      >>>  There are 2 problems:
>>      >>>    - it's a function type, so this means to introduce a new
>>      kind of type
>>      >>>  in the Java type system.
>>      >>>    - it allows to use void and the primitives types between the
>>      angle
>>      >>>  bracket
>>      >>>      which is not something allowed for the generics syntax.
>>      >>>
>>      >>  This is not so hard. Method handles are new phenoms to platform and
>>      >>  compiler can handle them specially as polymorphic signature method
>>      >>  invocations handed.
>>      >>
>>      >>  Best Regards,
>>      >>  Ali Ebrahimi
>>      >>
>>      >>    So this syntax was rejected for Java 8 but may be
>>      reconsidered later.
>>      >>>  Rémi
>>      >>>
>>      >>  I think I know what a method handle is.
>>      >>  Polymorphic signature method like MH.invoke or MH.invokeGeneric
>>      are handled
>>      >>  by bypassing the method resolution used by the compiler.
>>      >>  That's why you have to specify the return type when calling
>>      such methods.
>>      >>  To summarize, the compiler does nothing and let the VM checks
>>      at runtime if
>>      >>  the invocation is safe or not.
>>      >>
>>      >>  So you can't reuse this mechanism to implement function type.
>>      >>
>>      >  I don't mean reuse the same mechanism, my intent is specially
>>      applying of
>>      >  generic type parameters for MethodHandle reference types and
>>      allowing them
>>      >  take arbitrary number of  type parameters in declaration.
>>      >  In this case, the compiler does not check number and types of
>>      them and
>>      >  accept them as is and use them for checking of methodhandle
>>      invocation
>>      >  expresions .
>>      >
>>      >  MethodHandle<void,int>    mh1;
>>      >  MethodHandle<void,int,int>    mh2;
>>      >  MethodHandle  mh;
>>      >  ...
>>      >  mh1.invoke(1);
>>      >  mh2.invoke(1,2);
>>      >
>>      >  for generic MethodHandle reference as mh1, mh2 compiler checks
>>      applicability
>>      >  of passed args in methodhandle invocation expresions and for
>>      non-generic
>>      >  once as mh don't do this check and works as current mechanism.
>>      >  mh.invoke(1,2,3,4);
>>      >
>>      >  MethodHandle class itself does not any generic type parameters in
>>      >  definition.
>>
>>      But you just scratch the surface.
>>      What about sybtyping between MethodHandle function type,
>>      is a MethodHandle function type is a reified type,
>>      is wildcard of MethodHandle function type allowed, is capture allowed,
>>      is a MethodHandle function type can be inferred (what are the rules
>>      for such inference), etc ?
>>
>> I think, this idea is in raw state and each of the above cases should
>> be investigated. At first some of them can be supported. But any
>> solution must be possible forward compatible to kill the rest of the
>> battle.
>>
>> What do you think?
>
> [me trying to remember some shower session about that]
> I think you first need reification of generics if you want to be sure to
> don't introduce hazard.
>
> After, you just have to create a JSR :)
>
>>
>> Best Regards,
>> Ali Ebrahimi
>>
>
> regards,
> Rémi
>
>