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.

But could function types then be used as parameters or parameter bounds in parameterized types? There's no top function type in this scheme is it? Could implicit conversion relation be treated the same as sub-type relation in parameter bounds?


Regards, Peter