Re: [Caml-list] Strange crash after switching to first class modules

[John Carr <jfc@mit.edu>]

Xavier Leroy <Xavier.Leroy@inria.fr> 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?