Xavier Leroy <[email protected]> wrote:
> Could you first try to eliminate that partial application of fprintf?
> (Inline f at point of call, or eta-expand yourself.) The Printf
> module takes a lot of liberties with the type system (ahem), so it is
> one of the usual suspects in such a case.
The program still crashes if I eta expand. But it has a different
stack trace due to different tail calls and I think I understand
the problem:
Unpacking a module to provide a functor argument does not permute fields
to match the required signature.
I have a module that I use to represent another module plus another bit
of information paired with the base type of the other module.
module M : C with type t = t1 * t2 = struct
type t = t1 * t2
let format chan (a,b) = ... (* format first part then second part *)
and f1 (a1,b1) (a2,b2) = ...
and f2 (a1,b1) (a2,b2) = ...
and equal (a1,b1) (a2,b2) = ...
and hash (a1,b2) = ...
end
This module, packed into a value and unpacked, is the argument to the
Hashtbl.Make functor.
The stack trace goes from
Hashtbl.MakeSeeded.mem -> M.format -> another format function -> crash
Hashtbl.mem doesn't call the format method because there is no format
type in the functor argument. It calls equal. It reads the first
value in the module expecting an equal method and finding something
else.
I think the module value is not being reformatted to the type expected
by Hashtbl.Make.
Is this enough of a clue or do you want me to try cutting it down to
a smaller example?
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
