Comment author: administrator

From: sacerdot@cs.unibo.it

make will compile all the .mli files; then ocamlc will try to make
the .cmo and it will diverge (or at least require hundreds of
megabytes of RAM)

After looking desesparately for a bug, I have now the feeling that
this is just a complexity problem.
In particular, compilation terminates if you comment out method
[get_ownerDocument], line 347 of gdome.mli, which is the only reference
to [document] accessible from [element]. This greatly reduces the
accessible type graph, and is enough for the algorithm to terminate.

Why such a strange behaviour? Since module G is defined locally, all
references to it must disappear inside exported types. Since (element
: Gdome.element) is declared outside of the let module scope, applying
[aux] to [element] forces to eliminate all references to [G] in
[G.element_of_node]. Unfortunately, [G.element_of_node] does not
expand to [Gnome.element_of_node] but to its full object type. In turn
all types referencing G inside it must be expanded... Recursion is
handled, but this is still highly exponential, as your examples
exhibits.

If I'm not wrong, we will have to do something about that.

Jacques Garrigue

Comment author: administrator

The divergence problem due to mutually recursive definitions in
a locally opened module is now solved.

Note that the fix is only partial, and is just a side-effect on an optimization
caching expansions of types with no parameters. You can generate the same
problem by having mutual recursion between type abbreviations with parameters,
or using the -principal switch, which disables the caching :-(

Jacques Garrigue

Comment author: administrator

Partially solved by caching of expansions.