Functor compilation issue: Signature mismatch: Modules do not match - ocaml

Question

First the code:
module Boolean = struct
exception SizeMismatch
type boolean = T | F | Vec of boolean array
let to_bool v = match v with
T -> true
| F -> false
| _ -> raise SizeMismatch
end
module Logic = struct
type 'a var_t = { name: string; mutable value: 'a }
type 'a bexp = Const of 'a
| Var of 'a var_t
let eval exp = match exp with
Const x -> x
| Var x -> x.value
let make_var s v = { name = s; value = v }
let set v n = v.value <- n
let get_var_name v = v.name
let get_var_val v = v.value
end
module type EXP =
sig
type 'a var_t
type 'a bexp
val eval_exp : 'a bexp -> bool
val get_var_name : 'a var_t -> string
val get_var_val : 'a var_t -> 'a
end
module LogicExp =
struct
include Logic
let eval_exp exp = Boolean.to_bool (Logic.eval exp)
end
module FSM ( Exp : EXP ) =
struct
let print_var v = Printf.printf "%s = %d\n" (Exp.get_var_name v)
(Exp.get_var_val v)
end
module MyFSM = FSM(LogicExp)
let myvar = Logic.make_var "foo" 1;;
MyFSM.print_var myvar ;;
When I compile it I get the following error:
File "test.ml", line 57, characters 19-27:
Error: Signature mismatch:
Modules do not match:
sig
type 'a var_t =
'a Logic.var_t = {
name : string;
mutable value : 'a;
}
type 'a bexp = 'a Logic.bexp = Const of 'a | Var of 'a var_t
val eval : 'a bexp -> 'a
val make_var : string -> 'a -> 'a var_t
val set : 'a var_t -> 'a -> unit
val get_var_name : 'a var_t -> string
val get_var_val : 'a var_t -> 'a
val eval_exp : Boolean.boolean Logic.bexp -> bool
end
is not included in
EXP
Values do not match:
val eval_exp : Boolean.boolean Logic.bexp -> bool
is not included in
val eval_exp : 'a bexp -> bool
What I don't understand is how the more specific type isn't included in the more general type?

Answer 1

The error message is actually quite accurate:
Values do not match:
val eval_exp : Boolean.boolean Logic.bexp -> bool
is not included in
val eval_exp : 'a bexp -> bool
The MyFSM functor expects a module argument that, amongst other things, should contain a function eval_exp of type 'a bexp -> bool. That means that given a value of type 'a bexp for whatever choice of 'a the function should produce a value of type bool. You are, however, supplying a module that contains a function that only does this for one particular choice of 'a, i.e., the one where 'a is the type boolean from the module Boolean.
This quickest fix is to define your signature EXP as
module type EXP =
sig
type b (* added *)
type 'a var_t
type 'a bexp
val eval_exp : b bexp -> bool (* changed *)
val get_var_name : 'a var_t -> string
val get_var_val : 'a var_t -> 'a
end
so that eval_exp now operates on Boolean expressions over a fixed type b and then define LogicExp as
module LogicExp =
struct
type b = Boolean.boolean (* added *)
include Logic
let eval_exp exp = Boolean.to_bool (Logic.eval exp)
end
so that it fixes b to Boolean.boolean.
Implementing these changes will make your code compile.
Now, let us look at your question on "how the more specific type isn't included in the more general type?". This assumes that 'a bexp -> bool is indeed more general than boolean bexp -> bool, but in fact it isn't. A function type A -> B is considered more general than a function type C -> D if C is more general than A and B is more general than D:
A <: C D <: B
--------------------
C -> D <: A -> B
Note the "flipping" of C and A in the premise. We say that the function-space constructor ... -> ... is contravariant in its argument position (versus covariant in its result position).
Intuitively, a type is more general than another if it contains more values. To see why the function-space constructor is contravariant in its argument position, consider a function f of type A -> C for some types A and C. Now, consider a type B that is strictly more general than A, that is, all values in A are also in B, but B contains some values that are not in A. Thus, there is at least one value b to which we can assign type B, but not type A. Its type tells us that f knows how to operate on values of type A. However, if we were to (incorrectly!) conclude from A <: B that A -> C <: B -> C, then we could use f as if it had type B -> C and, hence, then we could pass the value b as an argument to f. But b is not of type A and f only knows how to operate on values of type A!
Clearly, covariance of ... -> ... in argument positions wouldn't work. To see that contravariance does work, consider the same types A, B, and C and now also consider a function g of type B -> C. That is, g knows how to operate on all values of type B. Contravariance of the function-space constructor in its argument position allows us to conclude that g can also be safely assigned the type A -> C. As we know that all values in A are also in B and g knows how to deal with all of B this poses no problems and we can safely pass values in A to g.