For what it's worth, last time I brought this up, it was mentioned that
some solutions have been proposed to this problem in the Standard ML
world:

http://cm.bell-labs.com/cm/cs/who/blume/pub.html

Also, here's a link to the previous discussion on google groups.

http://www.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=fa.ianr5dv.10n67hi%40ifi.uio.no&rnum=40&prev=/groups%3Fq%3Dgroup:fa.caml%2Bauthor:yminsky%2540cs.cornell.edu%26start%3D30%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dfa.ianr5dv.10n67hi%2540ifi.uio.no%26rnum%3D40

y

> I've asked this question before, but never quite got a satisfactory
> answer.  I'm hoping something has changed between now and then (maybe
> with 3.07?).
>
> Here's the issue.  Consider a project consisting of multiple modules
> with lots of interdependencies.   Imagine then that I want to add some
> flexibility to the system by abstracting out some of the structure of
> the system using a functor.  Thus, I start out with modules A, B, C, and
> I want to parameterize all these modules, let's say by the same module
> X.   So what I want is a version of the program where I can use A.F(X)
> intead of A, B.F(X) instead of B, and so on.  The problem is that I want
> to allow references between these modules.  Thus, B.F(X) needs access to
> A.F(X), and C.F(X) needs access to both A.F(X) and B.F(X).  The question
> is, is there a reasonable way to achieve this?
>
> I can think of an unreasonable way.  I can write the relevant functors
> so that they can be embedded in a unified module U as follows:
>
> module U =
> struct
>    module A = A.F(X)
>    module B = B.F(A,X)
>    module C = C.F(A,B,X)
> end
>
> In other words, B and C and require in their functors explicit arguments
> corresponding to the other modulse they need.  This works, but it's
> awfully ugly, not least because you have to write down some awful module
> signatures in B and C to make this work.
>
> Is there any non-awful way to achieve this?  The absence of this kind of
> feature makes the entire functor system seem much less attractive for
> adding any large-scale genericity.
>
> Yaron
>
>
> -------------------
> 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



-------------------
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