From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: weis
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id AAA01590 for caml-redistribution; Sun, 7 Jun 1998 00:02:29 +0200 (MET DST)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA02267 for <caml-list@pauillac.inria.fr>; Thu, 4 Jun 1998 20:27:48 +0200 (MET DST)
Received: from morgon.inria.fr (morgon.inria.fr [128.93.8.33])
	by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id UAA21548;
	Thu, 4 Jun 1998 20:27:42 +0200 (MET DST)
Received: (from remy@localhost)
	by morgon.inria.fr (8.8.7/8.8.7) id UAA08286;
	Thu, 4 Jun 1998 20:29:33 +0200
Message-ID: <19980604202933.14506@morgon.inria.fr>
Date: Thu, 4 Jun 1998 20:29:33 +0200
From: Didier Remy <remy@morgon.inria.fr>
To: Hendrik Tews <tews@tcs.inf.tu-dresden.de>
Cc: caml-list@inria.fr
Subject: Re: co(ntra)-variant subtyping
Reply-To: Didier.Remy@inria.fr
References: <199805201500.RAA19129@ithif18.inf.tu-dresden.de> <19980522112157L.garrigue@kurims.kyoto-u.ac.jp> <199805251146.NAA21664@ithif18.inf.tu-dresden.de> <19980526112435.51973@morgon.inria.fr> <199806041517.RAA00640@ithif18.inf.tu-dresden.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.85e
In-Reply-To: <199806041517.RAA00640@ithif18.inf.tu-dresden.de>; from Hendrik Tews on Thu, Jun 04, 1998 at 05:17:40PM +0200
Organization: INRIA, BP 105, F-78153 Le Chesnay Cedex
Phone: (33) 1 3963 5317 -- Sec: (33) 1 3963 5570 -- Fax: (33) 1 3963 5684
Web: http://pauillac.inria.fr/~remy
Sender: weis

> 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