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 Fri, 28 May 2004, Jacques GARRIGUE wrote:

> Yes, but by doing that you are breaking two things:
> * a .cmi does no longer depend only on the contents of the .mli
>   i.e., if you recompile twice the same library, then all the
>   dependencies must be recompiled, eventhough nothing has changed
>   (This may make bootstrapping the compiler rather complicated!
>    Every recompilation of the standard library would be incompatible.)

The method used for generating of the uid for a given unit can be decided
at compile time: one could compile some interfaces (like the stdlib) with
a "transparent" semantics (the uid is a hash of the name, the content of
the interface, and maybe a "salt" to be used as a namespace for the
library), and some with a generative semantics. The problem with the
transparent semantics is the one mentionned by Xavier (several modules
with the same name, same interface, different implementation, all linked
together), which should be extremely rare (does it happen for the whole
set of OCaml modules written so far) ?  The "salt" could handle these very
rare cases.

> * one can imagine a strange situation where you generated two
>   differents .cmo with the same .cmi (i.e. two .ml for one .mli, and
>   you compiled the .mli only once). Your scheme cannot cope with this
>   case: the two .cmo would conflict.
>   (I agree this is a bit far fetched)

Indeed, this is a bit far fetched. Given that the two .ml have the same
name, with the current scheme, you cannot link them together directly
(you could -pack them, or burry them in libraries, etc...)

> This looks like an attempt to solved the above compatibility problem.
> Do not change the semantics of interfaces, only the compilation of
> implementation.

Ok, thanks.

> Both imports and exports of libraries have "abstract" names (in
> practice unique ids, different for import and export) and the linker
> connects imports to the corresponding exports. Sound pretty powerful,
> and theoretically nice. But you get bigger .cmo/.cmx, and linking is
> more complex.

I don't see what the solution brings compared to the current scheme if one
stores names (and not only uids) in compiled units. In case of name
collision, how would the linker know what to do ?


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