[Caml-list] Mutually recursive dependent files

[Jan Rochel <jan@besport.com>]

I'm sure that most of you have tripped at one point or another over the problem
of OCaml not allowing for module files that mutually depend on each other. The
fact that this is possible for modules within the same file raises the
question: why not for module files?

If I had to guess I'd say that the following reasoning led to that limitation:
OCaml's semantics is script-like in that there is not a specific, explicitly
defined entry point (such as a main-function in C), but each file is
interpreted from top to bottom, so the order of the declarations within a file
is critically important (due to side effects they may have). This also pertains
to the order imposed on the module files before compilation and linking. (This
order is either imposed by the user or a dependency generator). Now if one were
to allow for recursive module files, then there would be no well-defined linear
order imposable on them and therefore the semantics would become ambiguous.

My first question:
Is this the actual reasoning behind the limitation or are there other (perhaps
more pertinent) reasons?

My contention:
The above-mentioned ambiguity already exists if a dependency generator is used.
If we have modules A -> B <- C, then there are two orders possible: BAC and
BCA. A and C may both produce side-effects within B during "initialisation" and
unexpected things might happen in B. Given this fact, it should already be
considered bad practice to write OCaml programs that are sensitive to module
linking order. But if OCaml programs already have to be written with this
semantic ambiguity in mind, then why not simply allow for mutually recursive
module files?

My second question:
If the answer to my first question is yes, and if my contention is to the
point, then I'd be curious to to know how difficult it would be to add a flag
to the OCaml compiler allowing for mutually recursive dependencies?

Jan