RE: [Caml-list] ocambuild vs ocamldep circular dependencies

["Soegtrop, Michael" <michael.soegtrop@intel.com>]

Dear Petter, Jonathan,

thanks for the hints! I think the function reference method is indeed a hack (it is also mentioned on http://wiki.xenproject.org/wiki/OCaml_Cyclical_Build_Dependencies ). The rec module approach is cleaner, but usually quite a bit of work. In the end I decided to rearrange my code so that the functions in question end up in one module. The effort is similar to the effort of implementing the module rec approach.

I still think that this is a substantial drawback of OCaml. It can be hard to foresee if one will stumble across this in larger projects, and it is not so nice that design decisions on the structure of modules are forced by this.

Couldn't one think of a way of declaring the existence of a module, with just its signature given? With such a mechanism, one could treat a reference to a module as a reference to the signature in the .mli file rather than to its implementation.

Best regards,

Michael

> -----Original Message-----
> From: Jonathan Protzenko [mailto:jonathan.protzenko@gmail.com]
> Sent: Saturday, July 09, 2016 10:10 PM
> To: Petter A. Urkedal
> Cc: Gabriel Scherer; caml-list@inria.fr; Soegtrop, Michael
> Subject: Re: [Caml-list] ocambuild vs ocamldep circular dependencies
> 
> FYI, here's how the source code of OCaml deals with this very problem.
> 
> https://github.com/ocaml/ocaml/blob/trunk/typing/typecore.ml#L84
> (forward reference...)
> 
> https://github.com/ocaml/ocaml/blob/trunk/typing/typemod.ml#L1564
> (filled later on).
> 
> Arguably a dirty hack, but works really nicely in practice imho. Works with
> OCamlbuild too.
> 
> ~ jonathan
> 
> On 7/9/16 9:16 AM, Petter A. Urkedal wrote:
> > There is a way to do it if I understood the problem right by
> > functorizing and linking explicitly with the `module rec` construct:
> >
> > $ cat first_sig.mli
> > module type S = sig
> >    type a
> >    type b
> >    val null : unit -> a
> >    val succ : b -> a
> > end
> >
> > $ cat second_sig.mli
> > module type S = sig
> >    type a
> >    type b
> >    val null : b
> >    val succ : a -> b
> > end
> >
> > $ cat first.ml
> > module Make (X : Second_sig.S) = struct
> >    type b = X.b
> >    type a = N | B of b
> >    let null () = N
> >    let succ x = B x
> > end
> >
> > $ cat second.ml
> > module Make (X : First_sig.S) = struct
> >    type a = X.a
> >    type b = N | A of a
> >    let null = N
> >    let succ x = A x
> > end
> >
> > $ cat both.ml
> > module rec A : First_sig.S with type b = B.b = First.Make (B)
> >         and B : Second_sig.S with type a = A.a = Second.Make (A)
> >
> > There are typically some shared types at the top of the signatures,
> > which could be put into a separate file and included.
> >
> >
> > On 9 July 2016 at 17:16, Soegtrop, Michael <michael.soegtrop@intel.com>
> wrote:
> >> Dear Gabriel,
> >>
> >>
> >>
> >> The current implementation happens to allow them, but this does not
> >> mean that they are "valid programs".
> >>
> >> I see what you mean: since I can’t put both modules into a single
> >> file without changing the two let into let rec / and or using
> >> recursive modules, it is not valid OCaml, although the compiler
> >> accepts it if presented separately.
> >>
> >>
> >>
> >> Let me see what I can do here. The mutual dependent part is a large
> >> part of both modules so it wouldn’t be very nice to put them into one
> >> file. But if it is the only option to get a valid OCaml program, I will look into
> it.
> >>
> >>
> >>
> >> Still I think it is unfortunate that OCaml doesn’t support this. It
> >> makes it harder to structure software in an aspect oriented way. For
> >> simple data structures it is fine to bundle all aspects into a single module
> or file.
> >> For a data structure like a C AST, the module / file will get quite
> >> large. I can separate off the statements easily, but this is only a
> >> small part of the AST. The largest part are expressions and types,
> >> and these are recursively dependent on each other.
> >>
> >>
> >>
> >> Best regards,
> >>
> >>
> >>
> >> Michael
> >>
> >> Intel Deutschland GmbH
> >> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> >> Tel: +49 89 99 8853-0, www.intel.de
> >> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> >> Chairperson of the Supervisory Board: Nicole Lau Registered Office:
> >> Munich Commercial Register: Amtsgericht Muenchen HRB 186928

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928