Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Circular module dependencies
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-09-07 (17:10)
From: Christopher Dutchyn <cdutchyn@c...>
Subject: Re: [Caml-list] Circular module dependencies

But what about (self- or mutually-) recursive modules?  By definition, 
they are cyclic, and neither suggested solution may work.  I use them to 
structure language semantics, and it's really convenient to have open 
recursion to different procedures and types.  I could restructure it into 
a single module, but then I couldn't mix-and-match.

I also appreciate the -rectypes option to Ocaml too; two-level types (a la 
Sheard and Pasalic) are elegant, and recursive types let me remove the 
superfluous tagging that Haskell needs.

So I think circularity is valuable, but I need to be careful to show my 
recursions are well-founded.

Christopher Dutchyn
UBC Computer Science

On Tue, 7 Sep 2004, Jacques GARRIGUE wrote:

> From: Tony Edgin <>
>> Recently, there was a thread which talked about how difficult module
>> dependencies were to resolve for linking in Ocaml.  I'm guessing this is
>> because of cycles in the dependency graph.
>> My thought is that maybe Ocaml shouldn't allow this to happen.  Wouldn't
>> cyclical module dependencies be a symptom of bad design?
> Bingo. Ocaml does not allow it. It just happens that you can cheat the
> compiler into accepting two different acyclic dependency graphs: one
> for the types (compilation order of the .mli's) and one for the values
> (compilation order of the .ml's). This was never intended, but there
> is no specific reason to go to great length to defeat that trick, as
> it is still safe.
> At least that's my take on the question.
>> If a cyclic dependency occurs I can think of two ways of removing.
> Indeed, this is the reasonable approach.
> ---------------------------------------------------------------------------
> Jacques Garrigue      Kyoto University     garrigue at
> 		<A HREF=>JG</A>
> -------------------
> To unsubscribe, mail Archives:
> Bug reports: FAQ:
> Beginner's list:

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: