Function types versus arrays

[Peter Levart]

On Saturday 13 February 2010 00:18:33 John Rose wrote:
> On Feb 12, 2010, at 3:06 PM, Alex Buckley wrote:
> > John Rose wrote:
> >> The best way I know of to tag function arrays is to define function
> >> arrays as pseudo-arrays which work at runtime like a
> >> Collections.checkedList but look at the source level like arrays.
> >> The most surprising wrinkle of such a design, IMO, is that they would
> >> fail to be subtypes of Object[], much like int[] fails today.
> >
> > This compilation strategy would also enable arrays of parameterized
> > types, and generally open the door to wonderful new type constructors
> > that are useful in source and whose representation is known to the JIT.
> > But unless we also change the compilation strategy for storing to an
> > Object[], the universal supertype will bite us every time. I feel like
> > we're peering over the edge of a very tall cliff.
> 
> Maybe there is a way to back up one step from that cliff, though it might
>  be off a different cliff (the erasure cliff).  How about this:
> 
> A function type is not a reference type.  Types are comprised of 1.
>  reference types, 2. primitive types, 3. function types.  (In the
>  bytecodes, function types can still be *represented* by references, of
>  course.)
> 
> Define one reference type FT (e.g., MethodHandle) as representing all
>  function types in the reference type hierarchy, via conversion.  FT will
>  serve as a an erased or raw holder type for all function types.
> 
> Add an implicit assignment conversion from any function type to FT.  (Cf.
>  List<T> to List.)
> 
> Add an explicit casting conversion from FT to any function type.  It does a
>  runtime check against some attribute query (e.g., MethodHandle.type).
> 
> After the smoke clears, we find that arrays of function types are not
>  related to the type FT[] or Object[].  Also, arrays of function types can
>  be pseudo-arrays.
> 
> We would still have a problem (which we did anyway) with representing
>  function types within field and method signatures.  In erased form, they
>  would look simply like FT.

Isn't JavaMethodHandle a way to bring diversity among function types' runtime representation? At 
least some diversity. Let's say function types were represented as parameterized subclasses of 
JavaMethodHandle (just like BGGA did with interfaces). Runtime representation would be their 
erased (raw) conterparts - this means that all subtype-related function types would be 
represented by a single JavaMethodHandle subclass at runtime. This would bring at least some 
runtime safety. The question of course is whether half-safety is better then no safety at all.

> 
> -- John
> 

Regards, Peter