Redundancy in OCaml type declaration (ml/mli)

Question

Hello, I'm trying to understand a specific thing about ocaml modules and their compilation:

am I forced to redeclare types already declared in a .mli inside the specific .ml implementations?

Just to give an example:

(* foo.mli *)
type foobar = Bool of bool | Float of float | Int of int

(* foo.ml *)
type baz = foobar option

This, according to my normal way of thinking about interfaces/implementations, should be ok but it says

Error: Unbound type constructor foobar

while trying to compile with

ocamlc -c foo.mli
ocamlc -c foo.ml

Of course the error disappears if I declare foobar inside foo.ml too but it seems a complex way since I have to keep things synched on every change.

Is there a way to avoid this redundancy or I'm forced to redeclare types every time?

Thanks in advance

Answer 1

Yes, you are forced to redeclare types. The only ways around it that I know of are

• Don't use a .mli file; just expose everything with no interface. Terrible idea.

• Use a literate-programming tool or other preprocessor to avoid duplicating the interface declarations in the One True Source. For large projects, we do this in my group.

For small projects, we just duplicate type declarations. And grumble about it.

Answer 2

You can let ocamlc generate the mli file for you from the ml file:

ocamlc -i some.ml > some.mli

Answer 3

In general, yes, you are required to duplicate the types.

You can work around this, however, with Camlp4 and the pa_macro syntax extension (findlib package: camlp4.macro). It defines, among other things, and INCLUDE construct. You can use it to factor the common type definitions out into a separate file and include that file in both the .ml and .mli files. I haven't seen this done in a deployed OCaml project, however, so I don't know that it would qualify as recommended practice, but it is possible.

The literate programming solution, however, is cleaner IMO.

Answer 4

Ocaml tries to force you to separate the interface (.mli) from the implementation (.ml. Most of the time, this is a good thing; for values, you publish the type in the interface, and keep the code in the implementation. You could say that Ocaml is enforcing a certain amount of abstraction (interfaces must be published; no code in interfaces).

For types, very often, the implementation is the same as the interface: both state that the type has a particular representation (and perhaps that the type declaration is generative). Here, there can be no abstraction, because the implementer doesn't have any information about the type that he doesn't want to publish. (The exception is basically when you declare an abstract type.)

One way to look at it is that the interface already contains enough information to write the implementation. Given the interface type foobar = Bool of bool | Float of float | Int of int, there is only one possible implementation. So don't write an implementation!

A common idiom is to have a module that is dedicated to type declarations, and make it have only a .mli. Since types don't depend on values, this module typically comes in very early in the dependency chain. Most compilation tools cope well with this; for example ocamldep will do the right thing. (This is one advantage over having only a .ml.)

The limitation of this approach is when you also need a few module definitions here and there. (A typical example is defining a type foo, then an OrderedFoo : Map.OrderedType module with type t = foo, then a further type declaration involving'a Map.Make(OrderedFoo).t.) These can't be put in interface files. Sometimes it's acceptable to break down your definitions into several chunks, first a bunch of types (types1.mli), then a module (mod1.mli and mod1.ml), then more types (types2.mli). Other times (for example if the definitions are recursive) you have to live with either a .ml without a .mli or duplication.