Question

Is there a reason why OCaml is not able to unroll intermediate parametrized types in a signature ?

For instance:

(* foo.ml *)
type 'a internal = Foo of 'a
type t = string internal

and:

(* foo.mli *)
type t = Foo of string

Give an error.

I guess this is releated to the fact that the memory representation can be different sometimes, but I was wondering if there is any deeper reason before submitting a bug report to the OCaml bug-tracker…

Answer 1

This is not a memory representation question. When matching a type declaration against a type signature, or more generally when checking if a declaration t1 is less general than a declaration t2, the type-checker currently considers only those three cases:

• t2 is an abstract type or type abbreviation
• t1 and t2 are both sum types
• t1 and t2 are both records

The other cases fail with an error. In your case, t1 (the type being checked) is a type abbreviation, and t2 (the specification) is a sum type. This fail with a type error.

See the source code: type_declarations in typing/includemod.ml.

This is not a memory representation consideration as foo.ml would fail with this as well:

type u = Foo of string
type t = u

Perhaps this check could be refined. You should ask on the bugtracker.

Edit: it’s not trivial to tell how far this check should be refined. It is not correct in general to expand abbreviations on the signature side when checking signature matching, for example the following should not be accepted:

module Test : sig
  type t = Foo
  type u = t (* to the outside, t and u would be equal *)
end = struct
  type t = Foo (* while internally they are different *)
  type u = Foo (* sum/records are generative/nominative *)
end

The other way around (an internal equality is hidden from the outside) is correct and already possible:

module Test : sig
  type t = Foo
  type u = Foo
end = struct
  type t = Foo
  type u = t = Foo
end;;

fun (x : Test.t) -> (x : Test.u);;
(* Error: This expression has type Test.t but an expression
   was expected of type Test.u *)

Now, memory representation also come into account when considering abbreviation expansion, as the dynamic semantics (memory representation choices) of the type system is not preserved by such expansions:

module Test : sig
  type r = { x : float; y : float; z : float } (* boxed float record *)
end = struct
  type 'a t = { x : 'a; y : 'a; z : 'a } (* polymorphic record *)
  type r = float t
end