Comment author: administrator

the OCaml 3.02 compiler does not like to compile this interface if a
compiled interface already exists:

/tmp > cat test.mli
module type MM = sig
end

module A : sig
module type T = sig
module T : MM
end
end

module EmptyT : A.T

/tmp > ocamlc -c -g test.mli # first time - works ok
/tmp > ocamlc -c -g test.mli # opens test.cmi over and over
Uncaught exception: Stack overflow

That's a very interesting bug, and I believe it's been around for
years -- probably since Caml Special Light. I think I have fixed it.
Since you're obviously using the module system intensively, would you
agree to test the fix? The patch (against 3.02) is attached below.

(One reason I'm asking you to test is that the fix renders module
type-checking exponential in the nesting depth of structures, I think
that should be OK in practice, but if you notice a major slowdown,
please tell me and I'll try to address the efficiency issue.)

Best wishes,

• Xavier Leroy

Index: typing/env.ml

RCS file: /net/pauillac/caml/repository/csl/typing/env.ml,v
retrieving revision 1.38
diff -u -r1.38 env.ml
--- typing/env.ml 2000/04/10 14:59:00 1.38
+++ typing/env.ml 2001/07/31 08:17:07
@@ -465,7 +465,7 @@
let comps = components_of_module !env sub path mty in
c.comp_components <-
Tbl.add (Ident.name id) (comps, !pos) c.comp_components;

•        env := store_components id path comps !env;
  

•        env := store_module id path mty !env;
         incr pos
     | Tsig_modtype(id, decl) ->
         let decl' = Subst.modtype_declaration sub decl in
  

@@ -591,18 +591,6 @@
classes = env.classes;
cltypes = env.cltypes;
summary = Env_modtype(env.summary, id, info) }

-and store_components id path comps env =

• { values = env.values;
• constrs = env.constrs;
• labels = env.labels;
• types = env.types;
• modules = env.modules;
• modtypes = env.modtypes;
• components = Ident.add id (path, comps) env.components;
• classes = env.classes;
• cltypes = env.cltypes;
• summary = env.summary }

and store_class id path desc env =
{ values = env.values;

Comment author: administrator

(One reason I'm asking you to test is that the fix renders module
type-checking exponential in the nesting depth of structures, I think
that should be OK in practice, but if you notice a major slowdown,
please tell me and I'll try to address the efficiency issue.)

I have noticed a significant slowdown, but it is a slowdown I can live
with. Of the following two files, newlib.ml is almost entirely
module stitchery', whereas luainterp.ml has lots of real' code.
The difference is that newlib contains a number of modules nested to
depth 4, where luainterp contains modules nested to depth at most 2,
and most of the code is at depth 1.

: nr@labrador 13072 ; /usr/bin/time ocamlc -I ../lib -g -c luainterp.ml
1.48user 0.01system 0:01.50elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (129major+1385minor)pagefaults 0swaps
: nr@labrador 13073 ; /usr/bin/time ocamlc -I ../lib -g -c newlib.ml
3.95user 0.04system 0:04.02elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (129major+1736minor)pagefaults 0swaps
: nr@labrador 13074 ; wc luainterp.ml newlib.ml
525 3523 18821 luainterp.ml
366 1988 12421 newlib.ml
891 5511 31242 total

I'll happily send the files if you wish to investigate.

Norman

Comment author: administrator

Fixed 2001-07-31 by XL.