Type definitions bind type constructors to data types: either variant types, record types, type abbreviations, or abstract data types. They also bind the value constructors and record fields associated with the definition.

Type definitions are introduced by the type keyword, and consist in one or several simple definitions, possibly mutually recursive, separated by the and keyword. Each simple definition defines one type constructor.
A simple definition consists in a lowercase identifier, possibly preceded by one or several type parameters, and followed by an optional type equation, then an optional type representation, and then a constraint clause. The identifier is the name of the type constructor being defined.
In the righthand side of type definitions, references to one of the type constructor name being defined are considered as recursive, unless type is followed by nonrec. The nonrec keyword was introduced in OCaml 4.02.2.
The optional type parameters are either one type variable ' ident, for type constructors with one parameter, or a list of type variables ('ident_{1},…,' ident_{n}), for type constructors with several parameters. Each type parameter may be prefixed by a variance constraint + (resp. ) indicating that the parameter is covariant (resp. contravariant). These type parameters can appear in the type expressions of the righthand side of the definition, optionally restricted by a variance constraint ; i.e. a covariant parameter may only appear on the right side of a functional arrow (more precisely, follow the left branch of an even number of arrows), and a contravariant parameter only the left side (left branch of an odd number of arrows). If the type has a representation or an equation, and the parameter is free (i.e. not bound via a type constraint to a constructed type), its variance constraint is checked but subtyping etc. will use the inferred variance of the parameter, which may be less restrictive; otherwise (i.e. for abstract types or nonfree parameters), the variance must be given explicitly, and the parameter is invariant if no variance is given.
The optional type equation = typexpr makes the defined type equivalent to the type expression typexpr: one can be substituted for the other during typing. If no type equation is given, a new type is generated: the defined type is incompatible with any other type.
The optional type representation describes the data structure representing the defined type, by giving the list of associated constructors (if it is a variant type) or associated fields (if it is a record type). If no type representation is given, nothing is assumed on the structure of the type besides what is stated in the optional type equation.
The type representation = [] constrdecl {  constrdecl } describes a variant type. The constructor declarations constrdecl_{1}, …, constrdecl_{n} describe the constructors associated to this variant type. The constructor declaration constrname of typexpr_{1} * … * typexpr_{n} declares the name constrname as a nonconstant constructor, whose arguments have types typexpr_{1} …typexpr_{n}. The constructor declaration constrname declares the name constrname as a constant constructor. Constructor names must be capitalized.
The type representation = { fielddecl { ; fielddecl } [;] } describes a record type. The field declarations fielddecl_{1}, …, fielddecl_{n} describe the fields associated to this record type. The field declaration fieldname : polytypexpr declares fieldname as a field whose argument has type polytypexpr. The field declaration mutable fieldname : polytypexpr behaves similarly; in addition, it allows physical modification of this field. Immutable fields are covariant, mutable fields are nonvariant. Both mutable and immutable fields may have a explicitly polymorphic types. The polymorphism of the contents is statically checked whenever a record value is created or modified. Extracted values may have their types instantiated.
The two components of a type definition, the optional equation and the optional representation, can be combined independently, giving rise to four typical situations:
The type variables appearing as type parameters can optionally be prefixed by + or  to indicate that the type constructor is covariant or contravariant with respect to this parameter. This variance information is used to decide subtyping relations when checking the validity of :> coercions (see section 6.7.6).
For instance, type +'a t declares t as an abstract type that is covariant in its parameter; this means that if the type τ is a subtype of the type σ, then τ t is a subtype of σ t. Similarly, type 'a t declares that the abstract type t is contravariant in its parameter: if τ is a subtype of σ, then σ t is a subtype of τ t. If no + or  variance annotation is given, the type constructor is assumed nonvariant in the corresponding parameter. For instance, the abstract type declaration type 'a t means that τ t is neither a subtype nor a supertype of σ t if τ is subtype of σ.
The variance indicated by the + and  annotations on parameters is enforced only for abstract and private types, or when there are type constraints. Otherwise, for abbreviations, variant and record types without type constraints, the variance properties of the type constructor are inferred from its definition, and the variance annotations are only checked for conformance with the definition.
The construct constraint ' ident = typexpr allows the specification of type parameters. Any actual type argument corresponding to the type parameter ident has to be an instance of typexpr (more precisely, ident and typexpr are unified). Type variables of typexpr can appear in the type equation and the type declaration.

Exception definitions add new constructors to the builtin variant
type exn
of exception values. The constructors are declared as
for a definition of a variant type.
The form exception constrname [of typexpr {* typexpr}] generates a new exception, distinct from all other exceptions in the system. The form exception constrname = constr gives an alternate name to an existing exception.