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