Function types versus arrays

[John Rose]

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.

-- John