Here is a stab at producing a BNF for types. I don’t mean a BNF for type expressions, but a BNF that produces one terminal for each type. The terminal productions are abstract trees and not character strings.

This is roughly what Freiburghaus did for PL/I declarations whose terminal productions modeled the meaning of a declarations regarding a particular new identifier, not the declaration syntax. I had used PL/I for several years and his BNF taught me new things about PL/I.

The html rendering of BNF in the OCaml manual pleases me but I won’t invest in doing that work manually, or automatically until I understand the necessary input to such a process. 

type = int | float | char | string | bool
     |
Time out!! I think I will try to define an OCaml type, each distinct value of which relates to some distinct OCaml type. This is rather like a ‘meta-circular’ definition as appeared on page 75 of the first LISP manual. This is the sort of type definition that might appear in an OCaml interpreter written in OCaml. It also avoids inventing a new BNF format and I can use OCaml to debug the expression!.

Contemplating the syntax of type expressions: 

type mtype = Int | Float | Char | String | Bool
           | Tuple of (mtype array)
           |
We need to add informally that the array is immutable and has at least two elements.

Many languages attempt to ensure that for every possible value there is an expression that yields said value. I don’t know if OCaml tries or succeeds at this. 

 “type q = B | C” is a [manual016.html#type-definition].
 “q = B | C” is a [manual016.html#typedef].
 “q” is a [manual016.html#typeconstr-name].
 “= B | C” is a [manual016.html#type-information].
 “= B | C” is a [manual016.html#type-representation].
 “B” is a [manual016.html#constr-decl].
 “B” is a [manual011.html#constr-name].