Re: co(ntra)-variant subtyping

From: Hendrik Tews (tews@tcs.inf.tu-dresden.de)
Date: Thu Jun 04 1998 - 17:17:40 MET DST


Date: Thu, 4 Jun 1998 17:17:40 +0200
Message-Id: <199806041517.RAA00640@ithif18.inf.tu-dresden.de>
From: Hendrik Tews <tews@tcs.inf.tu-dresden.de>
To: caml-list@inria.fr
Subject: Re: co(ntra)-variant subtyping
In-Reply-To: <19980526112435.51973@morgon.inria.fr>
 <19980522112157L.garrigue@kurims.kyoto-u.ac.jp>

Hi,

Didier Remy asked me for examples where the missing subtype rule
for Adt's is a problem ...

1. Assume you have windows, which allow you to ask for their
children:

class window : 'a =
  ...
  method children : 'a list
end

Now you can have a special kind of windows, which have special
children as well:

class transient_window : 'a =
  ...
  method children : 'a list
end

Now transient_window is not a subtype of window.

2. You can implement an automaton by modeling the states as
objects :

class automaton : 'a =
  ...
  method successor_state : 'a option
end

Again it is not possible to built a subtype of an automaton.

Didier Remy writes:

   Still, Objective Caml allows subtyping because they are a few situations
   when it is convenient. Typically, when storing a collection of
   objects of different subclasses of a common parent class into a bag. Then,
   only the operations of the parent class can be directly invoked on the
   objects of the collection.

Right. And you might use an Adt like the builtin lists for this
bag. But then a list of colored points can not be appended to a
list of points.
   
   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.

   We did not want to add yet another notion in the language, and therefore
   we prefered to make all non-primitive type constructors non variant.
   
I see. And what about an optional variance syntax, just for those
how want covariant lists?

Bye,

Hendrik



This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:14 MET