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

_______________________________________________
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

[Damien Guichard-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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

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

 

_______________________________________________
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

[Goswin von Brederlow-2]

"Damien Guichard" <alphablock@...> 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

_______________________________________________
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