On Thu, 1 Dec 2005, Jacques Garrigue wrote:

<snip>

> Yes, that's the idea.
> I should have been more specific:
> In order to create a clean separation between the library and the
> client, such that you will be able to change the implementation of the
> library, you must write .mli's for all the modules the library
> exports, and compile the client with only the .cmi's in the path.
> Note of course that the .mli/.cmi must also be copied to the directory
> where you compile the library (the compiler only looks for them there
> when compiling the .ml).
>
> A result is that there cannot be any inlining between client and
> library. Actually, this is even worse than that: this also prevents
> direct function calls, as the concrete information about functions is
> also in the .cmx. All calls will have to go through closures. Just
> like when you call a function received as parameter, or inside a
> functor.

A long while ago i wrote an unliner for .cmx to fight precisely this
problem, was quite trivial too, not that i ever understood the full
implications of this ofcourse.

>
> This suggests the other evident alternative: write the client as a
> functor. This will not be slower! But this can be more painful if
> there are several modules in the client...

-- 
mailto:malc@pulsesoft.com