Re: [Caml-list] Proposal for separate compilation

[Jacques GARRIGUE <garrigue@kurims.kyoto-u.ac.jp>]

From: Alain Frisch <Alain.Frisch@ens.fr>

> On Wed, 26 May 2004, Xavier Leroy wrote:

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

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.)
* 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)

The bootstrapping problem may be a show-stopper.
 
> Since you mention the generation of the unique identifier, I guess I
> missed something.

This looks like an attempt to solved the above compatibility problem.
Do not change the semantics of interfaces, only the compilation of
implementation.
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.

Jacques

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