caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Alain Frisch <Alain.Frisch@ens.fr>
To: Jacques GARRIGUE <garrigue@kurims.kyoto-u.ac.jp>
Cc: Caml list <caml-list@inria.fr>
Subject: Re: [Caml-list] Proposal for separate compilation
Date: Fri, 28 May 2004 11:55:06 +0200 (MET DST)	[thread overview]
Message-ID: <Pine.SOL.4.44.0405281112290.9983-100000@clipper.ens.fr> (raw)
In-Reply-To: <20040528.105427.68533454.garrigue@kurims.kyoto-u.ac.jp>

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


  parent reply	other threads:[~2004-05-28  9:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-21 16:32 Alain Frisch
2004-05-21 18:11 ` Richard Jones
2004-05-21 18:27 ` Nicolas Cannasse
2004-05-26  8:32 ` Xavier Leroy
2004-05-26 15:12   ` Nicolas Cannasse
2004-05-28  0:33   ` Alain Frisch
2004-05-28  1:54     ` Jacques GARRIGUE
2004-05-28  7:13       ` Nicolas Cannasse
2004-05-28  9:55       ` Alain Frisch [this message]
2004-05-28 10:14         ` Christian Lindig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.SOL.4.44.0405281112290.9983-100000@clipper.ens.fr \
    --to=alain.frisch@ens.fr \
    --cc=caml-list@inria.fr \
    --cc=garrigue@kurims.kyoto-u.ac.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).