Function types versus arrays

[John Rose]

On Feb 15, 2010, at 12:43 AM, Neal Gafter wrote:

> Where will this attribute come from?  If the lambda appears inside a
> generic method, the compiler cannot produce it statically.  And unless
> generics are reified, it cannot be generated dynamically either.

Right.  Such an attribute is intrinsic to the function object and therefore needs to be fully established when the object is created.  If a lambda is created by non-generic code, then all types are known by the compiler and can be baked in.

If a lambda is created by generic code, that code will be operating in terms of the bounds types of any type variables, so if the lambda is returned to code which "sees" only a certain instance of the generic type, the lambda will have a dynamic type which looks "unfinished" relative to the expectations of the calling code.  It may be that generic code can only be expected to build tightly-typed lambdas if it takes Class<T> arguments to go with relevant <T> parameters, so that lambdas can be created with the desired dynamic type.  For example, here are a couple of test cases:

  static <T, A extends T>
  #(A)->T identityFunction()
  // hard to infer A/T, must return concrete #(Object x)(x)
  { return #(A x)(x); }

  static <T>
  #()->T constantFunction(T x)
  // must return concrete #()((Object)x)
  { return type.cast( #()(x) ); }

  static <T, A extends T>
  #(A)->T identityFunction(FunctionType<#(A)->T> type)
  // assuming a suitable FunctionType.cast, all is well
  { return type.cast( #(A x)(x) ); }

  static <T>
  #()->T constantFunction(FunctionType<#()->T> type, T x)
  { return type.cast( #()(x) ); }

The dynamic cast functions would be required to build occasionally necessary bridges between erased types and their explicit reifications, as we do today with java.lang.Class.cast, etc.  Unlike Class.cast, FunctionType.cast would be specified to create a wrapper of the requested type.

-- John