Function types versus arrays

[John Rose]

On Feb 15, 2010, at 12:12 AM, Peter Levart wrote:

> But could function types then be used as parameters or parameter bounds in parameterized types?

Oops; thanks for picking up that point.  That's a serious flaw in the "tertium quid" version of function types I sketched.  Without function types under Object, we don't have List<#(int)->int>.  That's clearly a non-starter.

Or, we'd have to allow function types to be type bounds, even though they are not Objects, and then have an erasure story that went all the way to FT.  That sounds like plenty of trouble, too, although perhaps it is possible (in ways that primitive-typed type parameters are not possible; see below).

> There's no top function type in this scheme is it?

Nope, just FT which stands under Object but "to the side" (via conversion) of all the function types.

Because of contravariance, any function type with at least one parameter has a potentially infinite regression of supertypes, so there's no natural top type unless you force a peculiar 'FT' type into the system.

> Could implicit conversion relation be treated the same as sub-type relation in parameter bounds?

No, because of the following distinctions between subtyping and other implicit conversions:  All operations on a supertype work on a subtype; the subtype adds more operations or different behavior but does not subtract operations.  In addition subtype/supertype conversions do not change object identity.  These properties make generic code valid for all subtypes of type variable bounds (supertypes), even though the code operates (concretely) only on references of the bounds types.

Note that implicit conversions (such as int->Integer, int->double) can change bit patterns and/or object identity.  This makes it impractical to write reusable generic code that operates equally well on all implicitly-convertible relatives of a type.  Some implicit conversions even lose information, such as int->float or a null Integer to an int.  The stronger notion of reference subtyping is needed to build generic code.

(Oddly, the JLS refers to int as a subtype of double, etc., so primitive subtyping is a distinct and weaker notion compared to reference subtyping.  As far as generic code goes, there is no useful notion of primitive subtyping; primitives are too irregular.  But maybe function types are regular enough to make type variables with non-reference bounds.)

-- John