Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Proposal for separate compilation
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Alain Frisch <Alain.Frisch@e...>
Subject: Re: [Caml-list] Proposal for separate compilation
On Wed, 26 May 2004, Xavier Leroy wrote:

> This is an interesting proposal.  You might be interested in Martin
> Elsman's PhD (DIKU, 1998), which uses techniques along these lines in
> a defunctorizing, whole-program SML compiler.

Thanks for the pointer.

> There is one thing that puzzles me in your proposal.  Consider two
> compilation units A and B, where B refers to A.
>...
> So, what unique identifier is B going to use to refer to A's definition?
> Since A.cmi is the only available info on A, that
> identifier must be tied to A.cmi: either a hash of A's interface, or
> some unique identifier generated when A.mli is compiled into A.cmi.

If I understand the point correctly, an example would two modules
MyString1 and MyString2, with myString1.mli == myString2.mli:

type t = string
val compare: t -> t -> unit

but different implementations. One solution is simply, as Nicolas
suggests, to store the original name of the compilation unit in the uid.
Still, one could imagine two modules with the same name and the same
interface in unrelated libraries. This would be a good argument for using
reallly unique ids instead of hash. When you compile an interface a.mli,
you just mark a.cmi with a fresh random uid (with possibly a check that
the real content of a.cmi has been modified, otherwise don't touch the
uid). This will be used to make reference to module A from b.cmo (and of
course a.cmo). In other words: compilation of interfaces is given a
generative semantics.

Since you mention the generation of the unique identifier, I guess I
missed something.


-- Alain


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