English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
RE: [Caml-list] Modules and typing
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-05-02 (12:31)
From: Benedikt Grundmann <bgrundmann@g...>
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 :-)


GMX - Die Kommunikationsplattform im Internet.

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