In programming languages and type theory, parametric polymorphism allows a single piece of code to be given a "generic" type, using variables in place of actual types, and then instantiated with particular types as needed.^[1]: 340 Parametrically polymorphic functions and data types are sometimes called generic functions and generic datatypes, respectively, and they form the basis of generic programming.

Parametric polymorphism may be contrasted with ad hoc polymorphism. Parametrically polymorphic definitions are uniform: they behave identically regardless of the type they are instantiated at.^{[1]: 340 [2]: 37} In contrast, ad hoc polymorphic definitions are given a distinct definition for each type. Thus, ad hoc polymorphism can generally only support a limited number of such distinct types, since a separate implementation has to be provided for each type.

Basic definition

It is possible to write functions that do not depend on the types of their arguments. For example, the identity function ${\displaystyle {\mathsf {id}}(x)=x}$ simply returns its argument unmodified. This naturally gives rise to a family of potential types, such as ${\displaystyle {\mathsf {Int}}\to {\mathsf {Int}}}$, ${\displaystyle {\mathsf {Bool}}\to {\mathsf {Bool}}}$, ${\displaystyle {\mathsf {String}}\to {\mathsf {String}}}$, and so on. Parametric polymorphism allows ${\displaystyle {\mathsf {id}}}$ to be given a single, most general type by introducing a universally quantified type variable:

${\displaystyle {\mathsf {id}}:\forall \alpha .\alpha \to \alpha }$

The polymorphic definition can then be instantiated by substituting any concrete type for ${\displaystyle \alpha }$, yielding the full family of potential types.^[3]

The identity function is a particularly extreme example, but many other functions also benefit from parametric polymorphism. For example, an ${\displaystyle {\mathsf {append}}}$ function that concatenates two lists does not inspect the elements of the list, only the list structure itself. Therefore, ${\displaystyle {\mathsf {append}}}$ can be given a similar family of types, such as ${\displaystyle [{\mathsf {Int}}]\times [{\mathsf {Int}}]\to [{\mathsf {Int}}]}$, ${\displaystyle [{\mathsf {Bool}}]\times [{\mathsf {Bool}}]\to [{\mathsf {Bool}}]}$, and so on, where ${\displaystyle [T]}$ denotes a list of elements of type ${\displaystyle T}$. The most general type is therefore

${\displaystyle {\mathsf {append}}:\forall \alpha .[\alpha ]\times [\alpha ]\to [\alpha ]}$

which can be instantiated to any type in the family.

Parametrically polymorphic functions like ${\displaystyle {\mathsf {id}}}$ and ${\displaystyle {\mathsf {append}}}$ are said to be parameterized over an arbitrary type ${\displaystyle \alpha }$.^[4] Both ${\displaystyle {\mathsf {id}}}$ and ${\displaystyle {\mathsf {append}}}$ are parameterized over a single type, but functions may be parameterized over arbitrarily many types. For example, the ${\displaystyle {\mathsf {fst}}}$ and ${\displaystyle {\mathsf {snd}}}$ functions that return the first and second elements of a pair, respectively, can be given the following types:

${\displaystyle {\begin{aligned}{\mathsf {fst}}&:\forall \alpha .\forall \beta .\alpha \times \beta \to \alpha \\{\mathsf {snd}}&:\forall \alpha .\forall \beta .\alpha \times \beta \to \beta \end{aligned}}}$

In the expression ${\displaystyle {\mathsf {fst}}((3,{\mathsf {true}}))}$, ${\displaystyle \alpha }$ is instantiated to ${\displaystyle {\mathsf {Int}}}$ and ${\displaystyle \beta }$ is instantiated to ${\displaystyle {\mathsf {Bool}}}$ in the call to ${\displaystyle {\mathsf {fst}}}$, so the type of the overall expression is ${\displaystyle {\mathsf {Int}}}$.

The syntax used to introduce parametric polymorphism varies significantly between programming languages. For example, in some programming languages, such as Haskell, the ${\displaystyle \forall \alpha }$ quantifier is implicit and may be omitted.^[5] Other languages require types to be instantiated explicitly at some or all of a parametrically polymorphic function's call sites.

History

Parametric polymorphism was first introduced to programming languages in ML in 1975.^[6] Today it exists in Standard ML, OCaml, F#, Ada, Haskell, Mercury, Visual Prolog, Scala, Julia, Python, TypeScript, C++ and others. Java, C#, Visual Basic .NET and Delphi have each introduced "generics" for parametric polymorphism. Some implementations of type polymorphism are superficially similar to parametric polymorphism while also introducing ad hoc aspects. One example is C++ template specialization.

Predicativity, impredicativity, and higher-rank polymorphism

Rank-1 (predicative) polymorphism

This section needs additional citations for verification. Please help improve this article by adding citations to reliable sources in this section. Unsourced material may be challenged and removed. (February 2019) (Learn how and when to remove this message)

In a predicative type system (also known as a prenex polymorphic system), type variables may not be instantiated with polymorphic types.^{[1]: 359–360} Predicative type theories include Martin-Löf type theory and Nuprl. This is very similar to what is called "ML-style" or "Let-polymorphism" (technically ML's Let-polymorphism has a few other syntactic restrictions). This restriction makes the distinction between polymorphic and non-polymorphic types very important; thus in predicative systems polymorphic types are sometimes referred to as type schemas to distinguish them from ordinary (monomorphic) types, which are sometimes called monotypes.

A consequence of predicativity is that all types can be written in a form that places all quantifiers at the outermost (prenex) position. For example, consider the ${\displaystyle {\mathsf {append}}}$ function described above, which has the following type:

${\displaystyle {\mathsf {append}}:\forall \alpha .[\alpha ]\times [\alpha ]\to [\alpha ]}$

In order to apply this function to a pair of lists, a concrete type ${\displaystyle T}$ must be substituted for the variable ${\displaystyle \alpha }$ such that the resulting function type is consistent with the types of the arguments. In an impredicative system, ${\displaystyle T}$ may be any type whatsoever, including a type that is itself polymorphic; thus ${\displaystyle {\mathsf {append}}}$ can be applied to pairs of lists with elements of any type—even to lists of polymorphic functions such as ${\displaystyle {\mathsf {append}}}$ itself. Polymorphism in the language ML is predicative.^{[citation needed]} This is because predicativity, together with other restrictions, makes the type system simple enough that full type inference is always possible.

As a practical example, OCaml (a descendant or dialect of ML) performs type inference and supports impredicative polymorphism, but in some cases when impredicative polymorphism is used, the system's type inference is incomplete unless some explicit type annotations are provided by the programmer.

Higher-rank polymorphism

Some type systems support an impredicative function type constructor even though other type constructors remain predicative. For example, the type ${\displaystyle (\forall \alpha .\alpha \rightarrow \alpha )\rightarrow T}$ is permitted in a system that supports higher-rank polymorphism, even though ${\displaystyle [\forall \alpha .\alpha \rightarrow \alpha ]}$ may not be.^[7]

A type is said to be of rank k (for some fixed integer k) if no path from its root to a ${\displaystyle \forall }$ quantifier passes to the left of k or more arrows, when the type is drawn as a tree.^[1]: 359 A type system is said to support rank-k polymorphism if it admits types with rank less than or equal to k. For example, a type system that supports rank-2 polymorphism would allow ${\displaystyle (\forall \alpha .\alpha \rightarrow \alpha )\rightarrow T}$ but not ${\displaystyle ((\forall \alpha .\alpha \rightarrow \alpha )\rightarrow T)\rightarrow T}$. A type system that admits types of arbitrary rank is said to be "rank-n polymorphic".

Type inference for rank-2 polymorphism is decidable, but for rank-3 and above, it is not.^{[8][1]: 359}

Impredicative polymorphism

Impredicative polymorphism (also called first-class polymorphism) is the most powerful form of parametric polymorphism.^[1]: 340 In formal logic, a definition is said to be impredicative if it is self-referential; in type theory, it refers to the ability for a type to be in the domain of a quantifier it contains. This allows the instantiation of any type variable with any type, including polymorphic types. An example of a system supporting full impredicativity is System F, which allows instantiating ${\displaystyle \forall \alpha .\alpha \to \alpha }$ at any type, including itself.

In type theory, the most frequently studied impredicative typed λ-calculi are based on those of the lambda cube, especially System F.

Bounded parametric polymorphism

In 1985, Luca Cardelli and Peter Wegner recognized the advantages of allowing bounds on the type parameters.^[9] Many operations require some knowledge of the data types, but can otherwise work parametrically. For example, to check whether an item is included in a list, we need to compare the items for equality. In Standard ML, type parameters of the form ’’a are restricted so that the equality operation is available, thus the function would have the type ’’a × ’’a list → bool and ’’a can only be a type with defined equality. In Haskell, bounding is achieved by requiring types to belong to a type class; thus the same function has the type ${\textstyle \mathrm {Eq} \,\alpha \,\Rightarrow \alpha \,\rightarrow \left[\alpha \right]\rightarrow \mathrm {Bool} }$ in Haskell. In most object-oriented programming languages that support parametric polymorphism, parameters can be constrained to be subtypes of a given type (see the articles Subtype polymorphism and Generic programming).

See also

• Parametricity
• Polymorphic recursion
• Type class#Higher-kinded polymorphism
• Trait (computer programming)

Notes

References

• Hindley, J. Roger (1969), "The principal type scheme of an object in combinatory logic", Transactions of the American Mathematical Society, 146: 29–60, doi:10.2307/1995158, JSTOR 1995158, MR 0253905.
• Girard, Jean-Yves (1971). "Une Extension de l'Interpretation de Gödel à l'Analyse, et son Application à l'Élimination des Coupures dans l'Analyse et la Théorie des Types". Proceedings of the Second Scandinavian Logic Symposium. Studies in Logic and the Foundations of Mathematics (in French). Vol. 63. Amsterdam. pp. 63–92. doi:10.1016/S0049-237X(08)70843-7. ISBN 9780720422597.
• Girard, Jean-Yves (1972), Interprétation fonctionnelle et élimination des coupures de l'arithmétique d'ordre supérieur (Ph.D. thesis) (in French), Université Paris 7.
• Reynolds, John C. (1974), "Towards a Theory of Type Structure", Colloque Sur la Programmation, Lecture Notes in Computer Science, 19, Paris: 408–425, doi:10.1007/3-540-06859-7_148, ISBN 978-3-540-06859-4.
• Milner, Robin (1978). "A Theory of Type Polymorphism in Programming" (PDF). Journal of Computer and System Sciences. 17 (3): 348–375. doi:10.1016/0022-0000(78)90014-4. S2CID 388583.
• Cardelli, Luca; Wegner, Peter (December 1985). "On Understanding Types, Data Abstraction, and Polymorphism" (PDF). ACM Computing Surveys. 17 (4): 471–523. CiteSeerX 10.1.1.117.695. doi:10.1145/6041.6042. ISSN 0360-0300. S2CID 2921816.
• Pierce, Benjamin C. (2002). Types and Programming Languages. MIT Press. ISBN 978-0-262-16209-8.