Browse thread
RE: [Caml-list] Modules and typing
- Gurr, David (MED, self)
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2002-05-02 (19:28) |
From: | Gurr, David (MED, self) <David.Gurr@m...> |
Subject: | RE: [Caml-list] Modules and typing |
Hi, the .cmx files generated by ocamlopt do some of what you mention. -D > -----Original Message----- > From: Benedikt Grundmann [mailto:bgrundmann@gmx.net] > Sent: Thursday, May 02, 2002 5:31 AM > To: Gregory Morrisett > Cc: Francois.Pottier@inria.fr; skaller@ozemail.com.au; > caml-list@inria.fr > Subject: RE: [Caml-list] Modules and typing > > > > > + 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 ------------------- 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