caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques GARRIGUE <garrigue@kurims.kyoto-u.ac.jp>
To: tews@tcs.inf.tu-dresden.de
Cc: caml-list@inria.fr
Subject: Re: co(ntra)-variant subtyping
Date: Fri, 05 Jun 1998 14:45:58 +0900	[thread overview]
Message-ID: <19980605144558K.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: Your message of "Thu, 4 Jun 1998 17:17:40 +0200" <199806041517.RAA00640@ithif18.inf.tu-dresden.de>

From: Hendrik Tews <tews@tcs.inf.tu-dresden.de>

> 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:
[..]
> Now transient_window is not a subtype of window.

Probably not a very good example: I do not see here why children of
a transient window shall also be transient windows...

> 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. 

Better. There is still a way around, by raising an exception rather
than returning None, but agreedly this would not be very nice.

> 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.

And this variance checker is included in O'Labl. So your examples
would work.

>    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? 

This is a possibility. In fact I proposed such a syntax to Didier a
while ago. It would be needed only for abstract types, and one might
also ommit it when not interested in a type's variance: since most
O'Caml libraries are anyway compiled from source, you can always add
this information later if you need it.

However, I shall add that for me, the true problem with subtyping
under constructors is the complexity of the subtyping algorithm. The
current algorithm can easily explode, and subtyping under constructors
makes it even easier. So the real question might be: is it reasonable
to have the typability of a program depend on its size ?

	Jacques
---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>





      parent reply	other threads:[~1998-06-06 22:02 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
1998-06-04 18:29         ` Didier Remy
1998-06-05  5:45         ` Jacques GARRIGUE [this message]

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=19980605144558K.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=tews@tcs.inf.tu-dresden.de \
    /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).