Linking mutually dependent modules for fun

Linking mutually dependent modules for fun

[Dawid Toton]

I often get into trouble of cyclic dependencies when writing in OCaml.
Perhaps, I'm still not enough mentally shifted from poor languages (for
which circular design is quite natural).

Of course OCaml has many tools to deal with this: functors (which, once
introduced, spread like a disease), type variables and generalization
(which sometimes deadly collide with the functorial way) and ugly global
ref cells (which smell).

Why not try some Pascal style then? ;)
The following is what I got when studying OCaml's linking issues:

A.mli: val flip : unit -> unit
A.ml: let flip () = print_string "1"; B.flop ()  let _ = flip ()
B.mli: val flop : unit -> unit
B.ml: let flop () = print_string "0"; A.flip ()
C.ml: let _ = print_endline "C"

Compile:
ocamlopt -c -S A.ml
ocamlopt -c -S B.ml

The resulting .o depends on existing cmx files, so we can reach fixpoint
  by doing it once more:
ocamlopt -c -S A.ml

The new compiled A happens to work with uinitialized B.
Then use some helper module:
ocamlopt -c -S C.ml
ocamlopt -dstartup -ccopt --verbose C.cmx

Modify a.startup.s to call camlA_entry instead of camlC__entry.
as -o startup.o a.out.startup.s

Verbose gcc invocation gave us proper linking command.
Replace
...std_exit.o C.o /...../stdlib.a ...
with just
...std_exit.o A.o B.o /...../stdlib.a ...

And go!

OK, I must admit that I don't know how to get startup code that would
work in general. This one had wrong memory maps and no initialization of
B... anyway it works. :)

Dawid

Re: [Caml-list] Linking mutually dependent modules for fun

[Damien Guichard]

[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]

Hi Dawid,

Have you ever considered recursive modules ?
http://caml.inria.fr/pub/docs/manual-ocaml/manual021.html#toc75


- damien




En réponse au message
de : Dawid Toton
du : 2009-10-16 09:51:57
À : caml-list@yquem.inria.fr
CC : 
Sujet : [Caml-list] Linking mutually dependent modules for fun


I often get into trouble of cyclic dependencies when writing in OCaml.
Perhaps, I'm still not enough mentally shifted from poor languages (for
which circular design is quite natural).

Of course OCaml has many tools to deal with this: functors (which, once
introduced, spread like a disease), type variables and generalization
(which sometimes deadly collide with the functorial way) and ugly global
ref cells (which smell).

Why not try some Pascal style then? ;)
The following is what I got when studying OCaml's linking issues:

A.mli: val flip : unit - > unit
A.ml: let flip () = print_string "1"; B.flop ()  let _ = flip ()
B.mli: val flop : unit - > unit
B.ml: let flop () = print_string "0"; A.flip ()
C.ml: let _ = print_endline "C"

Compile:
ocamlopt -c -S A.ml
ocamlopt -c -S B.ml

The resulting .o depends on existing cmx files, so we can reach fixpoint
  by doing it once more:
ocamlopt -c -S A.ml

The new compiled A happens to work with uinitialized B.
Then use some helper module:
ocamlopt -c -S C.ml
ocamlopt -dstartup -ccopt --verbose C.cmx

Modify a.startup.s to call camlA_entry instead of camlC__entry.
as -o startup.o a.out.startup.s

Verbose gcc invocation gave us proper linking command.
Replace
...std_exit.o C.o /...../stdlib.a ...
with just
...std_exit.o A.o B.o /...../stdlib.a ...

And go!

OK, I must admit that I don't know how to get startup code that would
work in general. This one had wrong memory maps and no initialization of
B... anyway it works. :)

Dawid

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

[-- Attachment #2: Type: text/html, Size: 6871 bytes --]

Re: [Caml-list] Linking mutually dependent modules for fun

[Goswin von Brederlow]

"Damien Guichard" <alphablock@orange.fr> writes:

> Hi Dawid,
>
>  
>
> Have you ever considered recursive modules ?
>
> [[http://caml.inria.fr/pub/docs/manual-ocaml/manual021.html#toc75]]

The problem there is that that places everything in one file.

>> The following is what I got when studying OCaml's linking issues:
>> A.mli: val flip : unit - > unit
>> A.ml: let flip () = print_string "1"; B.flop ()  let _ = flip ()
>> B.mli: val flop : unit - > unit
>> B.ml: let flop () = print_string "0"; A.flip ()
>> C.ml: let _ = print_endline "C"

One solution is to use a closure argument to lift dependency out of A
into B:

A.mli: val flip : (unit -> unit) -> unit - > unit
A.ml: let flip flop () = print_string "1"; flop ()
B.mli: val flop : unit - > unit
B.ml: let rec flop () = print_string "0"; A.flip flop ()
C.ml: let _ = print_endline "C"; let _ = A.flip B.flop ()


I had the same problem myself several times and asked why ocaml does
not allow mutually dependencies of modules wheren each ml file only
depends on the other mli file. The reason I was given is
that ocaml does cross module inlining. That means B.ml depends on A.ml
(in its compiled form) for inlining and A.ml depends on B.ml for
inlining. So the dependency is not just on the mli files.

In say C the *.c files only depend on the *.h files and the mutual
dependencies between *.c files are only link time while in ocaml the
cross module inlining makes it a compile time issue.

MfG
        Goswin