## 17.3 Differences between Coq and ML type systems

Due to differences between Coq and ML type systems, some extracted programs are not typable in ML. For example, Here are two kinds of problem that can occur:

- If some part of the program is very polymorphic, there may be no ML type for it. In that case the extraction to ML works all right but the generated code may be refused by the ML type-checker. A very well known example is the distr-pair function:
  `Definition dp := [A,B:Set][x:A][y:B][f:(C:Set)C->C](f A x,f B y).`
  In Ocaml, for instance, the extracted term is `let dp x y f = pair((f () x),(f () y))` and has type
  `dp : 'a -> 'a -> (unit -> 'a -> 'b) -> ('b,'b) prod`
  which is not its original type, but a restriction.
- Some definitions of Coq may have no counterpart in ML. This happens when there is a quantification over types inside the type of a constructor; for example:
  `Inductive anything : Set := dummy : (A:Set)A->anything.`
  which corresponds to the definition of ML dynamics.

It is still possible to run the programs by switching off the type-checker during compilation. Unless you misused the semantical attachment facilities you should never get any message like ``segmentation fault'' for which the extracted code would be to blame. For example, to bypass the Ocaml type-checker, we can use the function `Obj.magic` which gives the type `'a` to any object. Work is underway to generate those `Obj.magic` automatically.
We have to say, though, that in most ``realistic'' programs, these problems do not occur. For example all the programs of the library are accepted by Caml type-checker (see examples below).