Re: co(ntra)-variant subtyping

[Didier Remy <remy@morgon.inria.fr>]

> 1. Assume you have windows, which allow you to ask for their
> children:
> ...
> Now transient_window is not a subtype of window.
>
> 2. You can implement an automaton by modeling the states as
> objects :
> ...
> Again it is not possible to built a subtype of an automaton. 

This is right.  You could only get deep subtyping if list and option
data-structures were implemented as objects (since then their types would be
abbreviations to objects types instead of data-types).

It is clear that the use of concrete data-types is better than objects here.
Concrete data-types are one of the nice features of ML, and we certainly do
not want to discourage (or limit) their use.

>    In fact, there is no real difficulty to allow subtyping through
>    user-declared type constructors.  However, when types are abstract
>    (e.g. in 
>    module interfaces) the user would need to declare the variances of the
>    constructors in their arguments.
>    
> This is actually more than I asked. For my application if would
> suffice if subtyping rules exist only for non-abstract types ie.
> variant and record types. There is no new syntax necessary for
> this, only a variance checker.

Your demand for covariant type-constructors is fair.

However, it is clear to me that restricting variances to concrete data-types
is just one small step forward and would not be  that satisfactory.

Today you only need covariance for non-abstract types, because you use lists
to collect windows.  But tomorrow, you'll create thousands of windows, and
you'll want to replace lists by sets or maps. Then you will need covariant
*abstract* type constructors.

The good solution is certainly to have variances, and explain them to the
user. We might consider such an extension in the future.

Thanks for you input.

Regards,

    -Didier