|logic||category theory||type theory|
|true||terminal object/(-2)-truncated object||h-level 0-type/unit type|
|false||initial object||empty type|
|proposition||(-1)-truncated object||h-proposition, mere proposition|
|cut rule||composition of classifying morphisms / pullback of display maps||substitution|
|cut elimination for implication||counit for hom-tensor adjunction||beta reduction|
|introduction rule for implication||unit for hom-tensor adjunction||eta conversion|
|logical conjunction||product||product type|
|disjunction||coproduct ((-1)-truncation of)||sum type (bracket type of)|
|implication||internal hom||function type|
|negation||internal hom into initial object||function type into empty type|
|universal quantification||dependent product||dependent product type|
|existential quantification||dependent sum ((-1)-truncation of)||dependent sum type (bracket type of)|
|equivalence||path space object||identity type|
|equivalence class||quotient||quotient type|
|induction||colimit||inductive type, W-type, M-type|
|higher induction||higher colimit||higher inductive type|
|completely presented set||discrete object/0-truncated object||h-level 2-type/preset/h-set|
|set||internal 0-groupoid||Bishop set/setoid|
|universe||object classifier||type of types|
|modality||closure operator, (idemponent) monad||modal type theory, monad (in computer science)|
|linear logic||(symmetric, closed) monoidal category||linear type theory/quantum computation|
|proof net||string diagram||quantum circuit|
|(absence of) contraction rule||(absence of) diagonal||no-cloning theorem|
|synthetic mathematics||domain specific embedded programming language|
|type theory||category theory|
|natural deduction||universal construction|
|dependent sum type||dependent sum|
Like any type constructor in type theory, the dependent 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.
The presentation of dependent sum type is almost exactly the same as that of product types, with the simple change that may depend on . In particular, they can be presented both as a negative type or as a positive type. In both cases, the rule for building the dependent sum type is the same:
but the constructors and eliminators may be different.
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 (to be the value of ) and one (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
When presented positively, primacy is given to the constructors. We specify that the way to construct something of type is to give a term and a term :
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.
Now we have the 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.
Inductive sig (A:Type) (B:A->Type) : Type := | exist : forall (x:A), B x -> sig 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.
In ordinary “nonlinear” type theory, the positive and negative dependent sum types are equivalent, just as in the case of product types. They manifestly have the same constructor, while we can define the eliminators in terms of each other as follows:
Also just as for product types, in order to recover the important 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. By inserting a transport, we can make do with a propositional -conversion, which is also provable from the dependent eliminator.
One might expect that in “dependent linear type theory” the positive and negative dependent sums would become different. However, the meaning of the quoted phrase is unclear.
Under categorical semantics, a dependent type corresponds to a fibration or display map . In this case, the dependent sum is just the object . This requires the dependent sum type to satisfy both - and -conversion.