7.10 Module types (module specifications)

Module types are the module-level equivalent of type expressions: theyspecify the general shape and type properties of modules.

See also the following language extensions:recovering the type of a module,substitution inside a signature,type-level module aliases,attributes,extension nodes andgenerative functors.

7.10.1 Simple module types

The expression modtype-path is equivalent to the module type boundto the name modtype-path.The expression (module-type) denotes the same type asmodule-type.

7.10.2 Signatures

Signatures are type specifications for structures. Signaturessig … end are collections of type specifications for valuenames, type names, exceptions, module names and module type names. Astructure will match a signature if the structure provides definitions(implementations) for all the names specified in the signature (andpossibly more), and these definitions meet the type requirements givenin the signature.

An optional ;; is allowed after each specification in asignature. It serves as a syntactic separator with no semanticmeaning.

Value specifications

A specification of a value component in a signature is writtenvalvalue-name: typexpr, where value-name is the name of thevalue and typexpr its expected type.

The form externalvalue-name: typexpr= external-declarationis similar, except that it requires in addition the name to beimplemented as the external function specified in external-declaration(see chapter 19).

Type specifications

A specification of one or several type components in a signature iswritten typetypedef { andtypedef } and consists of a sequenceof mutually recursive definitions of type names.

Each type definition in the signature specifies an optional typeequation =typexpr and an optional type representation=constr-decl … or ={field-decl … }.The implementation of the type name in a matching structure mustbe compatible with the type expression specified in the equation (ifgiven), and have the specified representation (if given). Conversely,users of that signature will be able to rely on the type equationor type representation, if given. More precisely, we have thefollowing four situations:

• Abstract type: no equation, no representation.
• Names that are defined as abstract types in a signature can beimplemented in a matching structure by any kind of type definition(provided it has the same number of type parameters). The exactimplementation of the type will be hidden to the users of thestructure. In particular, if the type is implemented as a variant typeor record type, the associated constructors and fields will not beaccessible to the users; if the type is implemented as anabbreviation, the type equality between the type name and theright-hand side of the abbreviation will be hidden from the users of thestructure. Users of the structure consider that type as incompatiblewith any other type: a fresh type has been generated.
• Type abbreviation: an equation =typexpr, no representation.
• The type name must be implemented by a type compatible with typexpr.All users of the structure know that the type name iscompatible with typexpr.
• New variant type or record type: no equation, a representation.
• The type name must be implemented by a variant type or record typewith exactly the constructors or fields specified. All users of thestructure have access to the constructors or fields, and can use themto create or inspect values of that type. However, users of thestructure consider that type as incompatible with any other type: afresh type has been generated.
• Re-exported variant type or record type: an equation,a representation.
• This case combines the previous two: the representation of the type ismade visible to all users, and no fresh type is generated.

Exception specification

The specification exceptionconstr-decl in a signature requires thematching structure to provide an exception with the name and argumentsspecified in the definition, and makes the exception available to allusers of the structure.

Class specifications

A specification of one or several classes in a signature is writtenclassclass-spec { andclass-spec } and consists of a sequenceof mutually recursive definitions of class names.

Class specifications are described more precisely insection 7.9.4.

Class type specifications

A specification of one or several classe types in a signature iswritten classtypeclasstype-def { andclasstype-def } andconsists of a sequence of mutually recursive definitions of class typenames. Class type specifications are described more precisely insection 7.9.5.

Module specifications

A specification of a module component in a signature is writtenmodulemodule-name: module-type, where module-name is thename of the module component and module-type its expected type.Modules can be nested arbitrarily; in particular, functors can appearas components of structures and functor types as components ofsignatures.

For specifying a module component that is a functor, one may write

modulemodule-name( name₁: module-type₁)… ( name_n: module-type_n): module-type

instead of

modulemodule-name:functor( name₁: module-type₁)-> …-> module-type

Module type specifications

A module type component of a signature can be specified either as amanifest module type or as an abstract module type.

An abstract module type specificationmoduletypemodtype-name allows the name modtype-name to beimplemented by any module type in a matching signature, but hides theimplementation of the module type to all users of the signature.

A manifest module type specificationmoduletypemodtype-name= module-typerequires the name modtype-name to be implemented by the module typemodule-type in a matching signature, but makes the equality betweenmodtype-name and module-type apparent to all users of the signature.

Opening a module path

The expression openmodule-path in a signature does not specifyany components. It simply affects the parsing of the following itemsof the signature, allowing components of the module denoted bymodule-path to be referred to by their simple names name instead ofpath accesses module-path. name. The scope of the openstops at the end of the signature expression.

Including a signature

The expression includemodule-type in a signature performs textualinclusion of the components of the signature denoted by module-type.It behaves as if the components of the included signature were copiedat the location of the include. The module-type argument mustrefer to a module type that is a signature, not a functor type.

7.10.3 Functor types

The module type expressionfunctor(module-name: module-type₁)-> module-type₂is the type of functors (functions from modules to modules) that takeas argument a module of type module-type₁ and return as result amodule of type module-type₂. The module type module-type₂ canuse the name module-name to refer to type components of the actualargument of the functor. If the type module-type₂ does notdepend on type components of module-name, the module type expressioncan be simplified with the alternative short syntax module-type₁-> module-type₂ .No restrictions are placed on the type of the functor argument; inparticular, a functor may take another functor as argument(“higher-order” functor).

7.10.4 The with operator

Assuming module-type denotes a signature, the expressionmodule-typewith mod-constraint { andmod-constraint } denotesthe same signature where type equations have been added to some of thetype specifications, as described by the constraints following thewith keyword. The constraint type [type-parameters] typeconstr= typexpr adds the type equation =typexpr to the specificationof the type component named typeconstr of the constrained signature.The constraint modulemodule-path= extended-module-path addstype equations to all type components of the sub-structure denoted bymodule-path, making them equivalent to the corresponding typecomponents of the structure denoted by extended-module-path.

For instance, if the module type name S is bound to the signature

        sig type t module M: (sig type u end) end

then S with type t=int denotes the signature

        sig type t=int module M: (sig type u end) end

and S with module M = N denotes the signature

        sig type t module M: (sig type u=N.u end) end

A functor taking two arguments of type S that share their t componentis written

        functor (A: S) (B: S with type t = A.t) ...

Constraints are added left to right. After each constraint has beenapplied, the resulting signature must be a subtype of the signaturebefore the constraint was applied. Thus, the with operator canonly add information on the type components of a signature, but neverremove information.