- 7.10.1Simple module types
- 7.10.2Signatures
- 7.10.3Functor types
- 7.10.4The with operator
Module types are the module-level equivalent of type expressions: theyspecify the general shape and type properties of modules.
| module-type | ::= | modtype-path |
| ∣ | sig{specification[;;]}end | |
| ∣ | functor(module-name:module-type)->module-type | |
| ∣ | module-type->module-type | |
| ∣ | module-typewithmod-constraint{andmod-constraint} | |
| ∣ | (module-type) | |
| mod-constraint | ::= | type[type-params]typeconstrtype-equation{type-constraint} |
| ∣ | modulemodule-path=extended-module-path | |
| specification | ::= | valvalue-name:typexpr |
| ∣ | externalvalue-name:typexpr=external-declaration | |
| ∣ | type-definition | |
| ∣ | exceptionconstr-decl | |
| ∣ | class-specification | |
| ∣ | classtype-definition | |
| ∣ | modulemodule-name:module-type | |
| ∣ | modulemodule-name{(module-name:module-type)}:module-type | |
| ∣ | moduletypemodtype-name | |
| ∣ | moduletypemodtype-name=module-type | |
| ∣ | openmodule-path | |
| ∣ | includemodule-type |
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.1Simple 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.2Signatures
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 writtenval value-name : typexpr, where value-name is the name of thevalue and typexpr its expected type.
The form external value-name : typexpr = external-declarationis similar, except that it requires in addition the name to beimplemented as the external function specified in external-declaration(see chapter20).
Type specifications
A specification of one or several type components in a signature iswritten type typedef { and typedef } 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 exception constr-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 writtenclass class-spec { and class-spec } and consists of a sequenceof mutually recursive definitions of class names.
Class specifications are described more precisely insection7.9.4.
Class type specifications
A specification of one or several classe types in a signature iswritten class type classtype-def { and classtype-def } andconsists of a sequence of mutually recursive definitions of class typenames. Class type specifications are described more precisely insection7.9.5.
Module specifications
A specification of a module component in a signature is writtenmodule module-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
module module-name ( name1 : module-type1 )… ( namen : module-typen ): module-type
instead of
module module-name :functor ( name1 : module-type1 ) -> …-> 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 specificationmodule type modtype-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 specificationmodule type modtype-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 open module-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 include module-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.3Functor types
The module type expressionfunctor ( module-name : module-type1 ) -> module-type2is the type of functors (functions from modules to modules) that takeas argument a module of type module-type1 and return as result amodule of type module-type2. The module type module-type2 canuse the name module-name to refer to type components of the actualargument of the functor. If the type module-type2 does notdepend on type components of module-name, the module type expressioncan be simplified with the alternative short syntax module-type1 -> module-type2 .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.4The with operator
Assuming module-type denotes a signature, the expressionmodule-type with mod-constraint { and mod-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 module module-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.
