From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Jocelyn.Serot@lasmea.univ-bpclermont.fr (Jocelyn Serot)
Cc: caml-list@margaux.inria.fr
Subject: Re: Q: Q: Module system and separate compilatioQ:
Date: Tue, 26 Mar 1996 17:04:02 +0100 (MET) [thread overview]
Message-ID: <199603261604.RAA14390@pauillac.inria.fr> (raw)
In-Reply-To: <199603211208.NAA07231@concorde.inria.fr> from "Jocelyn Serot" at Mar 21, 96 01:10:16 pm
> First of all, thanks to W. Lux and C. Boos for their clever answers
> to my last questions about the interaction between the module system
> and the file system. What i had not realized - it seems - is that
> the module language is _implicitely_ spoken within the file system
> and that functor application takes place automatically during the
> linking phase.
This is essentially correct: compilation units (files) are special
cases of structures (module-class objects). However, you can still do explicit
parameterization and explicit functor applications in a context of
separate compilation. That's because all module-class objects,
including functors, structures, and module types, can be components of
structures, hence components of compilation units.
> With the "all in same file, with explicit module declaration" approach , you
> can write:
>
> module type Bar = sig ... end
>
> module type Foo = sig ... end
>
> module Foo1 : Foo = struct ... (* 1st impl *) ... end
>
> module Foo2 : Foo = struct ... (* Another impl *) ... end
>
> module MakeBar(M: Foo) = (struct ... let double = ... Foo.add ... end : Bar)
>
> and then _choose_ to build a Bar implementation using either Foo1
>
> module Bar = MakeBar(Foo1)
>
> or Foo2
>
> module Bar = MakeBar(Foo2)
>
> How can you translate the same approach with the signatures and
> implementations for Foo and Bar being in distinct files (that is:
> foo.mli, foo1.ml, foo2.ml, bar.mli and bar.ml) ?
I would have the following compilation units:
* "foosig" contains the module type Foo
e.g. foosig.ml: module type Foo = sig ... end
and if you wish, foosig.mli with the same contents.
* "foo1" and "foo2" containing the two implementations
foo1.ml: module Foo = struct ... end
foo1.mli: module Foo : Foosig.Foo
foo2.ml: module Foo = struct ... end
foo2.mli: module Foo : Foosig.Foo
* "bar" containing the MakeBar functor and the Bar modtype
bar.ml: module type Bar = ...
module Make(M: Foosig.Foo) = ...
bar.mli: module type Bar = ...
module Make(M: Foosig.Foo): Bar
* "main1" and "main2" that choose between the two implementations
and starts up the whole program
main1.ml: module Bar = Bar.Make(Foo1.Foo) let _ = Bar.doit(); exit 0
main2.ml: module Bar = Bar.Make(Foo2.Foo) let _ = Bar.doit(); exit 0
Then, link-time configuration is achieved by linking either main1 or
main2 with the remainder of the compilation units.
So, it can be done. I'm not saying this is completely satisfactory,
and more support for link-time configuration could be desirable. On
the other hand, I'd hate to add a third language just for controlling
the linker...
- Xavier Leroy
prev parent reply other threads:[~1996-03-27 12:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-03-21 12:10 Jocelyn Serot
1996-03-26 16:04 ` Xavier Leroy [this message]
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=199603261604.RAA14390@pauillac.inria.fr \
--to=xavier.leroy@inria.fr \
--cc=Jocelyn.Serot@lasmea.univ-bpclermont.fr \
--cc=caml-list@margaux.inria.fr \
/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