Redirected from "pair type".
Contents
Contents
Idea
In type theory a product type of two types and is the type whose terms are ordered pairs with and .
In a model of the type theory in categorical semantics, this is a product. In set theory, it is a cartesian product. In dependent type theory, it is a special case of a dependent sum.
Note that a dependent product type is something different (a generalization of a function type).
Overview
(table taken from Myers et al.)
Definition
Like any type constructor in type theory (see at natural deduction), a product type is specified by rules saying when we can introduce it as a type, how to construct terms of that type, how to use or “eliminate” terms of that type, and how to compute when we combine the constructors with the eliminators.
In natural deduction
We assume that our product types have typal conversion rules, as those are the most general of the conversion rules. Both the propositional and judgmental conversion rules imply the typal conversion rules by the structural rules for propositional and judgmental equality respectively.
The formation and introduction rules are the same for both the positive and negative product types
Formation rules for product types:
Introduction rules for product types:
As a positive type
- Elimination rules for product types:
- Computation rules for product types:
- Uniqueness rules for product types:
Given a pointed h-proposition , the positive product type results in being an equivalence of types.
As a negative type
- Elimination rules for product types:
- Computation rules for product types:
- Uniqueness rules for product types:
Given a pointed h-proposition , the negative product type results in being a quasi-inverse function of , rather than an equivalence of types. Thus, the positive definition is preferred to the negative definition. Alternatively, the negative product type should be defined as a coinductive type rather than an inductive type.
As a special case of the dependent sum
In dependent type theory a product type is the special case the dependent sum over for the special case that is regarded as an -dependent type that actually happens to be -independent. The rules are given as follows:
As a special case of the dependent product
In dependent type theory given types and , one could define a type family indexed by elements of the two-valued type by and . A product type is a special case of the dependent product type
and is given by the following rules:
Formation rules for product types:
Introduction rules for product types:
Elimination rules for product types:
Computation rules for product types:
Uniqueness rules for product types:
Properties
Suppose and are types and is the negative product type of and . Then for all elements and , there is a function
There are functions and which are the function application to identities for the product projections and , which means for all identities , there are identities
Then, by the introduction rule for products, one could form the pair
with identites
for all .
Similarly, for all elements , , , , the binary function application to identities for defined in the introduction rule for product types is given by
inductively defined by the identities
For all elements and , the composition of functions
has domain and codomain .
By the uniqueness rule for the negative product type, there are identities and , and thus, for all identities , there are identities
For all elements , , and , , the composition of functions
has domain and codomain .
By the computation rules of the negative product type, there are identities , , , and , and for all pairs of identities , there are identities
Both of these square are in general not commutative squares.
In lambda-calculus
There are actually two ways to present product types, as a negative type or as a positive type. In both cases the type formation rule is the following:
but the constructors and eliminators may be different.
As a negative type
When presented negatively, primacy is given to the eliminators. We specify that there are two ways to eliminate a term of type : by projecting out the first component, or by projecting out the second.
This then determines the form of the constructors: in order to construct a term of type , we have to specify what value that term should yield when all the eliminators are applied to it. In other words, we have to specify a pair of elements, one of (to be the value of ) and one of (to be the value of ).
Finally, we have computation rules which say that the relationship between the constructors and the eliminators is as we hoped. We always have beta reduction rules
and we may or may not choose to have an eta reduction rule
As a positive type
When presented positively, primacy is given to the constructors. We specify that the way to construct something of type is to give something of type and something of type :
Of course, this is the same as the constructor obtained from the negative presentation. However, the eliminator is different. Now, in order to say how to use something of type , we have to specify how we should behave for all possible ways that it could have been constructed. In other words, we have to say, assuming that were of the form , what we want to do. Thus we end up with the following rule:
We need a term in the context of two variables of types and , and the destructor or match “binds those variables” to the two components of . Note that the “ordered pair” in the destructor is just a part of the syntax; it is not an instance of the constructor ordered pair. In dependent type theory, this elimination rule must be generalized to allow the type to depend on .
Now we have beta reduction rule:
In other words, if we build an ordered pair and then break it apart, what we get is just the things we put into it. (The notation means to substitute for and for in the term ).
And (if we wish) the eta reduction rule, which is a little more subtle:
This says that if we break something of type into its components, but then we only use those two components by way of putting them back together into an ordered pair, then we might as well just not have broken it down in the first place.
Positively defined products are naturally expressed as inductive types. For instance, in Coq syntax we have
Inductive prod (A B:Type) : Type :=
| pair : A -> B -> prod A B.
(Coq then implements beta-reduction, but not eta-reduction. However, eta-equivalence is provable with the internally defined identity type, using the dependent eliminator mentioned above.)
Arguably, negatively defined products should be naturally expressed as coinductive types, but this is not exactly the case for the presentation of coinductive types used in Coq.
Positive versus negative
In ordinary “nonlinear” type theory, the positive and negative product types are equivalent. They manifestly have the same constructor, while we can define the eliminators in terms of each other as follows:
It is obvious that the -reduction rules in the two cases correspond; see below for -conversion.
In dependent type theory, in order to recover the dependent eliminator for the positive product type from the eliminators for the negative product type, we need the latter to satisfy the -conversion rule so as to make the above definition well-typed. It is sufficient to have the -conversion up to propositional equality, however, if we are willing to insert a substitution along such an equality in the definition of the dependent eliminator. Conversely, the dependent eliminator for the positive product allows us to prove a propositional version of the negative -conversion (without assuming the positive -conversion). See propositional eta-conversions.
Now from -conversion for the negative product, we can also derive
so the defined positive product also satisfies its -conversion, which will be definitional or propositional according to that of the negative product.
On the other hand, if the positive product has a definitional -conversion, then for the defined negative product we have
Note that this involves a beta-reduction step and also a “backwards” -reduction step. So from positive reduction we cannot derive negative -reduction, only negative -equivalence. (However, the directionality of -reduction is somewhat questionable anyway.)
In conclusion, we have:
-
In non-dependent type theory, positive and negative products are equivalent, as are their definitional -reduction rules.
-
In dependent type theory with identity types, improving the positive eliminator to a dependent eliminator is equivalent to asserting propositional versions of either -conversion rule.
-
In any case, the two definitional -conversion rules also correspond.
It is of importance to note that these translations require the contraction rule and the weakening rule; that is, they duplicate and discard terms. In linear logic these rules are disallowed, and therefore the positive and negative products become different. The positive product becomes “tensor” , and the negative product becomes “with” .
Categorical interpretation
Under categorical semantics, product types satisfying both beta and eta conversions correspond to products in a category. More precisely:
-
categorical products may be used to interpret product types that validate both beta and eta rules, while
-
the syntactic category of a type theory with product types has categorical products, as long as the type theory satisfies both beta and eta rules.
Of course, the categorical notion of product matches the negative definition of a product most directly. In linear logic, therefore, the categorical product interprets “with” , while an additional monoidal structure interprets “tensor” . On the other hand, in a representable cartesian multicategory, the product has a “from the left” universal property which matches the positive definition.
There is also another interpretation in category theory of the product type and , as the initial -indexed family of parallel morphisms with source , the object with a family of morphisms
such that for any other object with a family of morphisms , there exists a unique morphism such that
This corresponds to the positive product types.
References
A textbook account in the context of programming languages is in section 11 of
On product types as inductive types:
- Kajetan Söhnen, §2.4.3 in : Higher Inductive Types in Homotopy Type Theory, Munich (2018) [pdf, pdf]