caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Benedikt Grundmann <bgrundmann@gmx.net>
To: "Gregory Morrisett" <jgm@CS.Cornell.EDU>
Cc: Francois.Pottier@inria.fr, skaller@ozemail.com.au, caml-list@inria.fr
Subject: RE: [Caml-list] Modules and typing
Date: Thu, 2 May 2002 14:31:07 +0200 (MEST)	[thread overview]
Message-ID: <22013.1020342667@www9.gmx.net> (raw)
In-Reply-To: <706871B20764CD449DB0E8E3D81C4D4301EE6D2B@opus.cs.cornell.edu>

> >  + require that abstract types are pointer types, as in 
> > Modula-3 (?) and, more
> >    recently, Cyclone
> 
> Actually, Cyclone has two different kinds of abstract types:
> One abstracts pointer types (really, types that are compatible
> with void*) and another kind that abstracts any type.  The latter
> kind can only be used under a pointer.  I think this corresponds more 
> closely to what Modula-3 provides with it's notion of "ref"
> types.  
> 
> There's another option that you didn't mention which is the approach
> taken by Ada:  Have a notion of "private" types in interfaces, e.g.
> 
>   type t
>   [private t = int]
> 
> The client is type-checked with t treated abstractly, but the 
> compiler can then specialize the client knowing what the implementation
> of t is.  Of course, by leaking this information into the interface,
> you're effectively losing separate compilation in the sense that
> if the implementation of t changes, then its interface must also
> change and all clients must then be (potentially) re-compiled.  But
> this is a simple option which avoids some of the complexity that
> you run into if you try to use abstract kinds to classify types
> according to implementation details that a compiler might need
> (e.g., size, calling-convention, and alignment constraints.)
> 
> -Greg

Another option related to this is to generate a compiler only interface file
(maybe even binary).  Which contains everything the compiler needs to know
about the implementation of an interface.  Everything mentioned above applies
to this solution too, with the added benefit that a reader of the interface
can't make stupid assumptions about the implementation which might not be true
in the next release :-)


Bene

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

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


  parent reply	other threads:[~2002-05-02 12:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-30 13:44 Gregory Morrisett
2002-04-30 23:57 ` John Max Skaller
2002-05-02 12:31 ` Benedikt Grundmann [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-05-02 19:27 Gurr, David (MED, self)
2002-04-29 13:35 [Caml-list] Polymorphic Variants and Number Parameterized Typ es Krishnaswami, Neel
2002-04-29 14:16 ` [Caml-list] Polymorphic Variants and Number Parameterized Types Andreas Rossberg
2002-04-29 15:28   ` Francois Pottier
2002-04-30 10:04     ` [Caml-list] Modules and typing John Max Skaller
2002-04-30 11:51       ` Francois Pottier
2002-04-30 23:24         ` John Max Skaller
2002-05-01  8:08           ` Noel Welsh
2002-05-02  6:52             ` Francois Pottier

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=22013.1020342667@www9.gmx.net \
    --to=bgrundmann@gmx.net \
    --cc=Francois.Pottier@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=jgm@CS.Cornell.EDU \
    --cc=skaller@ozemail.com.au \
    /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).