caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: vrotaru@seznam.cz
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] subtyping, polymorphism, higher order types.....
Date: Sat, 05 Jul 2003 11:21:26 +0900	[thread overview]
Message-ID: <20030705112126Q.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <20030704224521.7db3450f.vrotaru@seznam.cz>

From: Vasile Rotaru <vrotaru@seznam.cz>
> On Thu, 03 Jul 2003 10:33:15 -0400
> Shaddin Doghmi <shaddin@mitre.org> wrote:
> 
> > In my experiences with ocaml, one of the major frustrations i
> > constantly run into is the lack of subtyping. [..]

You should be a bit more precise: ocaml has both explicit subtyping
(for objects), and parametric polymorphism (which is also a form of
implicit subsumption). So what it does not have is only the form of
implicit subtyping you are used to, and which is incompatible with
most forms of type inference.

>   The Shaddin message (and other influences -- the most notable being
> the Oberon language) had induced me to an idea which I offer here for
> discussion. Open (or extensible) product types. Something like this
> 
>     type point = int * int * _ ;;
> 
> where the underscore stands for any sequences of types. Colour, taste,
> strangeness, etc.
> 
>   Now a function designed to work with with "point" will work with any
> type which is a "point" extension. Just now I cannot think of a good
> "ocamlish" syntax for extending types. Maybe?
> 
>     type color_point = <point> * int * _
> 
>   The big question is what this will do with the type system of Ocaml
> and whether it worth the pain..

This looks very much like an ocaml object type to me...
Is the absence of labels for fields important?

Note that you can also encode the above with polymorphism:

  type 'a point = int * int * 'a
  type 'a color_point = (int * 'a) point

The only trouble here is that there is no way to create heterogeneous
collections, since you cannot coerce a [unit color_point] to a [unit
point]. Actually, this just comes from a missing relation in the ocaml
type algebra: the type Obj.t is not recognized as a supertype for all
types. If this were the case then you would be able to write:
  let l = [ (p :> Obj.t point); (cp :> Obj.t point) ]

That would be easy enough to add, but is it that useful?

     Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  reply	other threads:[~2003-07-05  2:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-03 14:33 Shaddin Doghmi
2003-07-03 16:23 ` brogoff
2003-07-04  6:43 ` Daniel Weil
2003-07-04 20:45 ` Vasile Rotaru
2003-07-05  2:21   ` Jacques Garrigue [this message]
2003-07-05  7:46     ` Fernando Alegre
2003-07-05 15:07     ` Vasile Rotaru

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=20030705112126Q.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=vrotaru@seznam.cz \
    /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).