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.