caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Hendrik Tews <tews@tcs.inf.tu-dresden.de>
To: caml-list@inria.fr
Subject: Re: co(ntra)-variant subtyping
Date: Thu, 4 Jun 1998 17:17:40 +0200	[thread overview]
Message-ID: <199806041517.RAA00640@ithif18.inf.tu-dresden.de> (raw)
In-Reply-To: <19980526112435.51973@morgon.inria.fr>

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





  reply	other threads:[~1998-06-04 17:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-05-20 15:00 Subtype problem Hendrik Tews
1998-05-22  2:21 ` Jacques GARRIGUE
1998-05-25 11:46   ` co(ntra)-variant subtyping Hendrik Tews
1998-05-26  9:24     ` Didier Remy
1998-06-04 15:17       ` Hendrik Tews [this message]
1998-06-04 18:29         ` Didier Remy
1998-06-05  5:45         ` Jacques GARRIGUE

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199806041517.RAA00640@ithif18.inf.tu-dresden.de \
    --to=tews@tcs.inf.tu-dresden.de \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).