Add backlog based on comments from Andrea, implement some of them
This commit is contained in:
parent
879f5bab52
commit
251fcf1966
|
@ -3,5 +3,74 @@ Talk about structure of library:
|
||||||
|
|
||||||
What can I say about reusability?
|
What can I say about reusability?
|
||||||
|
|
||||||
Misc
|
Meeting with Andrea May 18th
|
||||||
====
|
============================
|
||||||
|
|
||||||
|
App. 2 in HoTT gives typing rule for pathJ including a computational
|
||||||
|
rule for it.
|
||||||
|
|
||||||
|
If you have this computational rule definitionally, then you wouldn't
|
||||||
|
need to use `pathJprop`.
|
||||||
|
|
||||||
|
In discussion-section I mention HITs. I should remove this or come up
|
||||||
|
with a more elaborate example of something you could do, e.g.
|
||||||
|
something with pushouts in the category of sets.
|
||||||
|
|
||||||
|
The type Prop is a type where terms are *judgmentally* equal not just
|
||||||
|
propositionally so.
|
||||||
|
|
||||||
|
Maybe mention that Andreas Källberg is working on proving the
|
||||||
|
initiality conjecture.
|
||||||
|
|
||||||
|
Intensional Type Theory (ITT): Judgmental equality is decidable
|
||||||
|
|
||||||
|
Extensional Type Theory (ETT): Reflection is enough to make judgmental
|
||||||
|
equality undecidable.
|
||||||
|
|
||||||
|
Reflection : a ≡ b → a = b
|
||||||
|
|
||||||
|
ITT does not have reflections.
|
||||||
|
|
||||||
|
HTT ~ ITT + axiomatized univalence
|
||||||
|
Agda ~ ITT + K-rule
|
||||||
|
Coq ~ ITT (no K-rule)
|
||||||
|
Cubical Agda ~ ITT + Path + Glue
|
||||||
|
|
||||||
|
Prop is impredicative in Coq (whatever that means)
|
||||||
|
|
||||||
|
Prop ≠ hProp
|
||||||
|
|
||||||
|
Comments about abstract
|
||||||
|
-----
|
||||||
|
|
||||||
|
Pattern matching for paths (?)
|
||||||
|
|
||||||
|
Intro
|
||||||
|
-----
|
||||||
|
Main feature of judgmental equality is the conversion rule.
|
||||||
|
|
||||||
|
Conor explained: K + eliminators ≡ pat. matching
|
||||||
|
|
||||||
|
Explain jugmental equality independently of type-checking
|
||||||
|
|
||||||
|
Soundness for equality means that if `x = y` then `x` and `y` must be
|
||||||
|
equal according to the theory/model.
|
||||||
|
|
||||||
|
Decidability of `=` is a necessary condition for typechecking to be
|
||||||
|
decidable.
|
||||||
|
|
||||||
|
Canonicity is a nice-to-have though without canonicity terms can get
|
||||||
|
stuck. If we postulate results about judgmental equality. E.g. funext,
|
||||||
|
then we can construct a term of type natural number that is not a
|
||||||
|
numeral. Therefore stating canonicity with natural numbers:
|
||||||
|
|
||||||
|
∀ t . ⊢ t : N , ∃ n : N . ⊢ t = sⁿ 0 : N
|
||||||
|
|
||||||
|
is a sufficient condition to get a well-behaved equality.
|
||||||
|
|
||||||
|
Eta-equality for RawFunctor means that the associative law for
|
||||||
|
functors hold definitionally.
|
||||||
|
|
||||||
|
Computational property for funExt is only relevant in two places in my
|
||||||
|
whole formulation. Univalence and gradLemma does not influence any
|
||||||
|
proofs.
|
||||||
|
|
74
doc/appendix/abstract-funext.tex
Normal file
74
doc/appendix/abstract-funext.tex
Normal file
|
@ -0,0 +1,74 @@
|
||||||
|
\chapter{Abstract functional extensionality}
|
||||||
|
\label{app:abstract-funext}
|
||||||
|
In two places in my formalization was the computational behaviours of
|
||||||
|
functional extensionality used. The reduction behaviour can be
|
||||||
|
disabled by marking functional extensionality as abstract. Below the
|
||||||
|
fully normalized goal and context with functional extensionality
|
||||||
|
marked abstract has been shown. The excerpts are from the module
|
||||||
|
%
|
||||||
|
\begin{center}
|
||||||
|
\sourcelink{Cat.Category.Monad.Voevodsky}
|
||||||
|
\end{center}
|
||||||
|
%
|
||||||
|
where this is also written as a comment next to the proofs. When
|
||||||
|
functional extensionality is not abstract the goal and current value
|
||||||
|
are the same. It is of course necessary to show the fully normalized
|
||||||
|
goal and context otherwise the reduction behaviours is not forced.
|
||||||
|
|
||||||
|
\subsubsection*{First goal}
|
||||||
|
Goal:
|
||||||
|
\begin{verbatim}
|
||||||
|
PathP (λ _ → §2-3.§2 omap (λ {z} → pure))
|
||||||
|
(§2-fromMonad
|
||||||
|
(.Cat.Category.Monad.toKleisli ℂ
|
||||||
|
(.Cat.Category.Monad.toMonoidal ℂ (§2-3.§2.toMonad m))))
|
||||||
|
(§2-fromMonad (§2-3.§2.toMonad m))
|
||||||
|
\end{verbatim}
|
||||||
|
Have:
|
||||||
|
\begin{verbatim}
|
||||||
|
PathP
|
||||||
|
(λ i →
|
||||||
|
§2-3.§2 K.IsMonad.omap
|
||||||
|
(K.RawMonad.pure
|
||||||
|
(K.Monad.raw
|
||||||
|
(funExt (λ m₁ → K.Monad≡ (.Cat.Category.Monad.toKleisliRawEq ℂ m₁))
|
||||||
|
i (§2-3.§2.toMonad m)))))
|
||||||
|
(§2-fromMonad
|
||||||
|
(.Cat.Category.Monad.toKleisli ℂ
|
||||||
|
(.Cat.Category.Monad.toMonoidal ℂ (§2-3.§2.toMonad m))))
|
||||||
|
(§2-fromMonad (§2-3.§2.toMonad m))
|
||||||
|
\end{verbatim}
|
||||||
|
\subsubsection*{Second goal}
|
||||||
|
Goal:
|
||||||
|
\begin{verbatim}
|
||||||
|
PathP (λ _ → §2-3.§1 omap (λ {X} → pure))
|
||||||
|
(§1-fromMonad
|
||||||
|
(.Cat.Category.Monad.toMonoidal ℂ
|
||||||
|
(.Cat.Category.Monad.toKleisli ℂ (§2-3.§1.toMonad m))))
|
||||||
|
(§1-fromMonad (§2-3.§1.toMonad m))
|
||||||
|
\end{verbatim}
|
||||||
|
Have:
|
||||||
|
\begin{verbatim}
|
||||||
|
PathP
|
||||||
|
(λ i →
|
||||||
|
§2-3.§1
|
||||||
|
(RawFunctor.omap
|
||||||
|
(Functor.raw
|
||||||
|
(M.RawMonad.R
|
||||||
|
(M.Monad.raw
|
||||||
|
(funExt
|
||||||
|
(λ m₁ → M.Monad≡ (.Cat.Category.Monad.toMonoidalRawEq ℂ m₁)) i
|
||||||
|
(§2-3.§1.toMonad m))))))
|
||||||
|
(λ {X} →
|
||||||
|
fst
|
||||||
|
(M.RawMonad.pureNT
|
||||||
|
(M.Monad.raw
|
||||||
|
(funExt
|
||||||
|
(λ m₁ → M.Monad≡ (.Cat.Category.Monad.toMonoidalRawEq ℂ m₁)) i
|
||||||
|
(§2-3.§1.toMonad m))))
|
||||||
|
X))
|
||||||
|
(§1-fromMonad
|
||||||
|
(.Cat.Category.Monad.toMonoidal ℂ
|
||||||
|
(.Cat.Category.Monad.toKleisli ℂ (§2-3.§1.toMonad m))))
|
||||||
|
(§1-fromMonad (§2-3.§1.toMonad m))
|
||||||
|
\end{verbatim}
|
|
@ -1,55 +1,99 @@
|
||||||
\chapter{Perspectives}
|
\chapter{Perspectives}
|
||||||
\section{Discussion}
|
\section{Discussion}
|
||||||
In the previous chapter the practical aspects of proving things in Cubical Agda
|
In the previous chapter the practical aspects of proving things in
|
||||||
were highlighted. I also demonstrated the usefulness of separating ``laws'' from
|
Cubical Agda were highlighted. I also demonstrated the usefulness of
|
||||||
``data''. One of the reasons for this is that dependencies within types can lead
|
separating ``laws'' from ``data''. One of the reasons for this is that
|
||||||
to very complicated goals. One technique for alleviating this was to prove that
|
dependencies within types can lead to very complicated goals. One
|
||||||
certain types are mere propositions.
|
technique for alleviating this was to prove that certain types are
|
||||||
|
mere propositions.
|
||||||
|
|
||||||
\subsection{Computational properties}
|
\subsection{Computational properties}
|
||||||
Another aspect (\TODO{That I actually did not highlight very well in the
|
The new contribution of cubical Agda is that it has a constructive
|
||||||
previous chapter}) is the computational nature of paths. Say we have
|
proof of functional extensionality\index{functional extensionality}
|
||||||
formalized this common result about monads:
|
and univalence\index{univalence}. This means that in particular that
|
||||||
|
the type checker can reduce terms defined with these theorems. So one
|
||||||
|
interesting result of this development is how much this influenced the
|
||||||
|
development. In particular having a functional extensionality that
|
||||||
|
``computes'' should simplify some proofs.
|
||||||
|
|
||||||
\TODO{Some equation\ldots}
|
I have tested this theory by using a feature of Agda where one can
|
||||||
|
mark certain bindings as being \emph{abstract}. This means that the
|
||||||
|
type-checker will not try to reduce that term further when
|
||||||
|
type-checking is performed. I tried making univalence and functional
|
||||||
|
extensionality abstract. It turns out that the conversion behaviour of
|
||||||
|
univalence is not used anywhere. For functional extensionality there
|
||||||
|
are two places in the whole solution where the reduction behaviour is
|
||||||
|
used to simplify some proofs. This is in showing that the maps between
|
||||||
|
the two formulations of monads are inverses. See the notes in this
|
||||||
|
module:
|
||||||
|
%
|
||||||
|
\begin{center}
|
||||||
|
\sourcelink{Cat.Category.Monad.Voevodsky}
|
||||||
|
\end{center}
|
||||||
|
%
|
||||||
|
I've also put this in a source listing in \ref{app:abstract-funext}. I
|
||||||
|
will not reproduce it in full here as the type is quite involved. The
|
||||||
|
method used to find in what places the computational behaviour of
|
||||||
|
these proofs are needed has the caveat of only working for places that
|
||||||
|
directly or transitively uses these two proofs. Fortunately though the
|
||||||
|
code is structured in such a way that this should be the case.
|
||||||
|
Nonetheless it is quite surprising that this computational behaviours
|
||||||
|
is not used more widely in the formalization.
|
||||||
|
|
||||||
By transporting this to the Kleisli formulation we get a result that we can use
|
Barring this, however, the computational behaviour of paths can still
|
||||||
to compute with. This is particularly useful because the Kleisli formulation
|
be useful. E.g. if a programmer want's to reuse functions that operate
|
||||||
will be more familiar to programmers e.g.\ those coming from a background in
|
on a monoidal monads to work with a monad in the Kleisli form that
|
||||||
Haskell. Whereas the theory usually talks about monoidal monads.
|
this programmer has specified. To make this idea concrete, say we are
|
||||||
|
given some function $f \tp \Kleisli \to T$ having a path between $p
|
||||||
\TODO{Mention that with postulates we cannot do this}
|
\tp \Monoidal \equiv \Kleisli$ induces a map $\coe\ p \tp \Monoidal
|
||||||
|
\to \Kleisli$. We can compose $f$ with this map to get $f \comp
|
||||||
|
\coe\ p \tp \Monoidal \to T$. Of course, since that map was
|
||||||
|
constructed with an isomorphism these maps already exist and could be
|
||||||
|
used directly. So this is arguably only interesting when one wants to
|
||||||
|
prove properties of such functions.
|
||||||
|
|
||||||
\subsection{Reusability of proofs}
|
\subsection{Reusability of proofs}
|
||||||
The previous example also illustrate how univalence unifies two otherwise
|
The previous example illustrate how univalence unifies two otherwise
|
||||||
disparate areas: The category-theoretic study of monads; and monads as in
|
disparate areas: The category-theoretic study of monads; and monads as
|
||||||
functional programming. Univalence thus allows one to reuse proofs. You could
|
in functional programming. Univalence thus allows one to reuse proofs.
|
||||||
say that univalence gives the developer two proofs for the price of one.
|
You could say that univalence gives the developer two proofs for the
|
||||||
|
price of one. As an illustration of this I proved that monads are
|
||||||
|
groupoids. I initially proved this for the Kleisli
|
||||||
|
formulation\footnote{Actually doing this directly turned out to be
|
||||||
|
tricky as well, so I defined an equivalent formulation which was not
|
||||||
|
formulated with a record, but purely with $\sum$-types.}. Since the
|
||||||
|
two formulations are equal under univalence, substitution directly
|
||||||
|
gives us that this also holds for the monoidal formulation. This of
|
||||||
|
course generalizes to any family $P \tp 𝒰 → 𝒰$ where $P$ is inhabited
|
||||||
|
at either formulation (i.e.\ either $P\ \Monoidal$ or $P\ \Kleisli$
|
||||||
|
holds).
|
||||||
|
|
||||||
The introduction (section \S\ref{sec:context}) mentioned an often
|
The introduction (section \S\ref{sec:context}) mentioned an often
|
||||||
employed-technique for enabling extensional equalities is to use the
|
employed-technique for enabling extensional equalities is to use the
|
||||||
setoid-interpretation. Nowhere in this formalization has this been necessary,
|
setoid-interpretation. Nowhere in this formalization has this been
|
||||||
$\Path$ has been used globally in the project as propositional equality. One
|
necessary, $\Path$ has been used globally in the project as
|
||||||
interesting place where this becomes apparent is in interfacing with the Agda
|
propositional equality. One interesting place where this becomes
|
||||||
standard library. Multiple definitions in the Agda standard library have been
|
apparent is in interfacing with the Agda standard library. Multiple
|
||||||
designed with the setoid-interpretation in mind. E.g. the notion of ``unique
|
definitions in the Agda standard library have been designed with the
|
||||||
|
setoid-interpretation in mind. E.g. the notion of ``unique
|
||||||
existential'' is indexed by a relation that should play the role of
|
existential'' is indexed by a relation that should play the role of
|
||||||
propositional equality. Likewise for equivalence relations, they are indexed,
|
propositional equality. Likewise for equivalence relations, they are
|
||||||
not only by the actual equivalence relation, but also by another relation that
|
indexed, not only by the actual equivalence relation, but also by
|
||||||
serve as propositional equality.
|
another relation that serve as propositional equality.
|
||||||
%% Unfortunately we cannot use the definition of equivalences found in the
|
%% Unfortunately we cannot use the definition of equivalences found in
|
||||||
%% standard library to do equational reasoning directly. The reason for this is
|
%% the standard library to do equational reasoning directly. The
|
||||||
%% that the equivalence relation defined there must be a homogenous relation,
|
%% reason for this is that the equivalence relation defined there must
|
||||||
%% but paths are heterogeneous relations.
|
%% be a homogenous relation, but paths are heterogeneous relations.
|
||||||
|
|
||||||
In the formalization at present a significant amount of energy has been put
|
In the formalization at present a significant amount of energy has
|
||||||
towards proving things that would not have been needed in classical Agda. The
|
been put towards proving things that would not have been needed in
|
||||||
proofs that some given type is a proposition were provided as a strategy to
|
classical Agda. The proofs that some given type is a proposition were
|
||||||
simplify some otherwise very complicated proofs (e.g.
|
provided as a strategy to simplify some otherwise very complicated
|
||||||
\ref{eq:proof-prop-IsPreCategory} and \label{eq:productPath}). Often these
|
proofs (e.g. \ref{eq:proof-prop-IsPreCategory}
|
||||||
proofs would not be this complicated. If the J-rule holds definitionally the
|
and \label{eq:productPath}). Often these proofs would not be this
|
||||||
proof-assistant can help simplify these goals considerably. The lack of the
|
complicated. If the J-rule holds definitionally the proof-assistant
|
||||||
J-rule has a significant impact on the complexity of these kinds of proofs.
|
can help simplify these goals considerably. The lack of the J-rule has
|
||||||
|
a significant impact on the complexity of these kinds of proofs.
|
||||||
|
|
||||||
\TODO{Universe levels.}
|
\TODO{Universe levels.}
|
||||||
|
|
||||||
|
@ -60,15 +104,16 @@ Jesper Cockx' work extending the universe-level-laws for Agda and the
|
||||||
|
|
||||||
\subsection{Compiling Cubical Agda}
|
\subsection{Compiling Cubical Agda}
|
||||||
\label{sec:compiling-cubical-agda}
|
\label{sec:compiling-cubical-agda}
|
||||||
Compilation of program written in Cubical Agda is currently not supported. One
|
Compilation of program written in Cubical Agda is currently not
|
||||||
issue here is that the backends does not provide an implementation for the
|
supported. One issue here is that the backends does not provide an
|
||||||
cubical primitives (such as the path-type). This means that even though the
|
implementation for the cubical primitives (such as the path-type).
|
||||||
path-type gives us a computational interpretation of functional extensionality,
|
This means that even though the path-type gives us a computational
|
||||||
univalence, transport, etc., we do not have a way of actually using this to
|
interpretation of functional extensionality, univalence, transport,
|
||||||
compile our programs that use these primitives. It would be interesting to see
|
etc., we do not have a way of actually using this to compile our
|
||||||
practical applications of this. The path between monads that this library
|
programs that use these primitives. It would be interesting to see
|
||||||
exposes could provide one particularly interesting case-study.
|
practical applications of this. The path between monads that this
|
||||||
|
library exposes could provide one particularly interesting case-study.
|
||||||
|
|
||||||
\subsection{Higher inductive types}
|
\subsection{Higher inductive types}
|
||||||
This library has not explored the usefulness of higher inductive types in the
|
This library has not explored the usefulness of higher inductive types
|
||||||
context of Category Theory.
|
in the context of Category Theory.
|
||||||
|
|
9
doc/feedback-meeting-andrea.txt
Normal file
9
doc/feedback-meeting-andrea.txt
Normal file
|
@ -0,0 +1,9 @@
|
||||||
|
App. 2 in HoTT gives typing rule for pathJ including a computational
|
||||||
|
rule for it.
|
||||||
|
|
||||||
|
If you have this computational rule definitionally, then you wouldn't
|
||||||
|
need to use `pathJprop`.
|
||||||
|
|
||||||
|
In discussion-section I mention HITs. I should remove this or come up
|
||||||
|
with a more elaborate example of something you could do, e.g.
|
||||||
|
something with pushouts in the category of sets.
|
|
@ -1,42 +1,64 @@
|
||||||
\chapter{Introduction}
|
\chapter{Introduction}
|
||||||
This thesis is a case-study in the application of Cubical Agda in the
|
This thesis is a case-study in the application of cubical Agda in the
|
||||||
context of category theory. At the center of this is the notion of
|
context of category theory. At the center of this is the notion of
|
||||||
\nomenindex{equality}. In type-theory there are two pervasive notions
|
\nomenindex{equality}. In type-theory there are two pervasive notions
|
||||||
of equality: \nomenindex{judgmental equality} and
|
of equality: \nomenindex{judgmental equality} and
|
||||||
\nomenindex{propositional equality}. Judgmental equality is a property
|
\nomenindex{propositional equality}. Judgmental equality is a property
|
||||||
of the type system, it is a property that is automatically checked by
|
of the type system. Judgmental equality on the other hand is usually
|
||||||
a type checker. As such there are some properties judgmental
|
defined \emph{within} the system. When introducing definitions this
|
||||||
equalities must crucially have. It must be \nomenindex{decidable},
|
report will use the notation $\defeq$. Judgmental equalities written
|
||||||
\nomenindex{sound}, enjoy \nomenindex{canonicity} and be a
|
$=$. For propositional equalities the notation $\equiv$ is used.
|
||||||
\nomen{congruence relation}. Being decidable simply means that that an
|
|
||||||
algorithm exists to decide whether two terms are equal. For any
|
For judgmental equality there are some properties that it must
|
||||||
practical implementation the decidability must also be effectively
|
satisfy. \nomenindex{sound}, enjoy \nomenindex{canonicity} and be a
|
||||||
computable. Soundness means that things judged to be equal actually
|
\nomen{congruence relation}. Soundness means that things judged to be
|
||||||
\emph{are} considered equal. It must be a congruence relation because
|
equal are equal with respects to the model of the theory (the meta
|
||||||
otherwise the relation certainly does not adhere to our notion of
|
theory). It must be a congruence relation because otherwise the
|
||||||
equality. One would be able to conclude things like: $x \nequiv y
|
relation certainly does not adhere to our notion of equality. One
|
||||||
\rightarrow f\ x \equiv f\ y$. Canonicity will be explained later in
|
would be able to conclude things like: $x \equiv y \rightarrow f\ x
|
||||||
this introduction after we've seen an example of judgmental- and
|
\nequiv f\ y$. Canonicity means that any well typed term evaluates to
|
||||||
propositional equality at play for a simple example.\TODO{How to
|
a \emph{canonical} form. For example for a closed term $e \tp \bN$ it
|
||||||
motivate canonicity for equality}.
|
will be the case that $e$ reduces to $n$ applications of
|
||||||
|
$\mathit{suc}$ to $0$ for some $n$; $e = \mathit{suc}^n\ 0$. Without
|
||||||
|
canonicity terms in the language can get ``stuck'' -- meaning that
|
||||||
|
they do not reduce to a canonical form.
|
||||||
|
|
||||||
|
To work as a programming languages it is necessary for judgmental
|
||||||
|
equality to be \nomenindex{decidable}. Being decidable simply means
|
||||||
|
that that an algorithm exists to decide whether two terms are equal.
|
||||||
|
For any practical implementation the decidability must also be
|
||||||
|
effectively computable.
|
||||||
|
|
||||||
For propositional equality the decidability requirement is relaxed. It
|
For propositional equality the decidability requirement is relaxed. It
|
||||||
is not in general possible to decide the correctness of logical
|
is not in general possible to decide the correctness of logical
|
||||||
propositions (cf.\ Hilbert's \emph{entscheidigungsproblem}).
|
propositions (cf.\ Hilbert's \emph{entscheidigungsproblem}).
|
||||||
Propositional equality are provided by the developer. When introducing
|
|
||||||
definitions this report will use the notation $\defeq$. Judgmental
|
There are two flavors of type-theory. \emph{Intensional-} and
|
||||||
equalities written $=$. For propositional equalities the notation
|
\emph{extensional-} type theory. Identity types in extensional type
|
||||||
$\equiv$ is used.
|
theory are required to be \nomen{propositions}{proposition}. That is,
|
||||||
|
a type with at most one inhabitant. In extensional type thoery the
|
||||||
|
principle of reflection
|
||||||
|
%
|
||||||
|
$$a ≡ b → a = b$$
|
||||||
|
%
|
||||||
|
is enough to make type checking undecidable. This report focuses on
|
||||||
|
Agda which at a glance can be thought of a version of intensional type
|
||||||
|
theory. Pattern-matching in regular Agda let's one prove
|
||||||
|
\nomenindex{axiom K}. Axiom K states that any two identity proofs are
|
||||||
|
propositionally identical.
|
||||||
|
|
||||||
The usual notion of propositional equality in \nomenindex{Intensional
|
The usual notion of propositional equality in \nomenindex{Intensional
|
||||||
Type Theory} (ITT) is quite restrictive. In the next section a few
|
Type Theory} (ITT) is quite restrictive. In the next section a few
|
||||||
motivating examples will highlight this. There exist techniques to
|
motivating examples will highlight this. There exist techniques to
|
||||||
circumvent these problems, as we shall see. This thesis will explore
|
circumvent these problems, as we shall see. This thesis will explore
|
||||||
an extension to Agda that redefines the notion of propositional
|
an extension to Agda that redefines the notion of propositional
|
||||||
equality and as such is an alternative to these other techniques. What
|
equality and as such is an alternative to these other techniques. The
|
||||||
makes this extension particularly interesting is that it gives a
|
extension is called cubical Agda. Cubical Agda drops Axiom K as this
|
||||||
\emph{constructive} interpretation of univalence. What this means will
|
does not permit \nomenindex{functional extensionality} and
|
||||||
be elaborated in the following sections.
|
\nomenindex{univalence}. What makes this extension particularly
|
||||||
|
interesting is that it gives a \emph{constructive} interpretation of
|
||||||
|
univalence. What all this means will be elaborated in the following
|
||||||
|
sections.
|
||||||
%
|
%
|
||||||
\section{Motivating examples}
|
\section{Motivating examples}
|
||||||
%
|
%
|
||||||
|
@ -192,22 +214,16 @@ There are alternative approaches to working in a cubical setting where
|
||||||
one can still have univalence and functional extensionality. One
|
one can still have univalence and functional extensionality. One
|
||||||
option is to postulate these as axioms. This approach, however, has
|
option is to postulate these as axioms. This approach, however, has
|
||||||
other shortcomings, e.g. you lose \nomenindex{canonicity}
|
other shortcomings, e.g. you lose \nomenindex{canonicity}
|
||||||
(\TODO{Pageno!} \cite{huber-2016}). Canonicity means that any well
|
(\TODO{Pageno!} \cite{huber-2016}).
|
||||||
typed term evaluates to a \emph{canonical} form. For example for a
|
|
||||||
closed term $e \tp \bN$ it will be the case that $e$ reduces to $n$
|
|
||||||
applications of $\mathit{suc}$ to $0$ for some $n$; $e =
|
|
||||||
\mathit{suc}^n\ 0$. Without canonicity terms in the language can get
|
|
||||||
``stuck'' -- meaning that they do not reduce to a canonical form.
|
|
||||||
|
|
||||||
Another approach is to use the \emph{setoid interpretation} of type
|
Another approach is to use the \emph{setoid interpretation} of type
|
||||||
theory (\cite{hofmann-1995,huber-2016}). With this approach one works
|
theory (\cite{hofmann-1995,huber-2016}). With this approach one works
|
||||||
with
|
with \nomenindex{extensional sets} $(X, \sim)$, that is a type $X \tp
|
||||||
\nomenindex{extensional sets} $(X, \sim)$, that is a type $X \tp \MCU$
|
\MCU$ and an equivalence relation $\sim\ \tp X \to X \to \MCU$ on that
|
||||||
and an equivalence relation $\sim\ \tp X \to X \to \MCU$ on that type.
|
type. Under the setoid interpretation the equivalence relation serve
|
||||||
Under the setoid interpretation the equivalence relation serve as a
|
as a sort of ``local'' propositional equality. Since the developer
|
||||||
sort of ``local'' propositional equality. Since the developer gets to
|
gets to pick this relation it is not guaranteed to be a congruence
|
||||||
pick this relation it is not guaranteed to be a congruence relation
|
relation a priori. So this must be verified manually by the developer.
|
||||||
a priori. So this must be verified manually by the developer.
|
|
||||||
Furthermore, functions between different setoids must be shown to be
|
Furthermore, functions between different setoids must be shown to be
|
||||||
setoid homomorphism, that is; they preserve the relation.
|
setoid homomorphism, that is; they preserve the relation.
|
||||||
|
|
||||||
|
|
|
@ -124,3 +124,6 @@
|
||||||
\newcommand{\doclink}{\hrefsymb{\sourcebasepath}{\texttt{\sourcebasepath}}}
|
\newcommand{\doclink}{\hrefsymb{\sourcebasepath}{\texttt{\sourcebasepath}}}
|
||||||
\newcommand{\clll}{\mathrel{\bC.\mathord{\lll}}}
|
\newcommand{\clll}{\mathrel{\bC.\mathord{\lll}}}
|
||||||
\newcommand{\dlll}{\mathrel{\bD.\mathord{\lll}}}
|
\newcommand{\dlll}{\mathrel{\bD.\mathord{\lll}}}
|
||||||
|
\newcommand\coe{\varindex{coe}}
|
||||||
|
\newcommand\Monoidal{\varindex{Monoidal}}
|
||||||
|
\newcommand\Kleisli{\varindex{Kleisli}}
|
||||||
|
|
|
@ -62,9 +62,10 @@
|
||||||
\nocite{coquand-2013}
|
\nocite{coquand-2013}
|
||||||
|
|
||||||
\bibliography{refs}
|
\bibliography{refs}
|
||||||
%% \begin{appendices}
|
\begin{appendices}
|
||||||
%% \setcounter{page}{1}
|
\setcounter{page}{1}
|
||||||
%% \pagenumbering{roman}
|
\pagenumbering{roman}
|
||||||
|
\input{appendix/abstract-funext.tex}
|
||||||
%% \input{sources.tex}
|
%% \input{sources.tex}
|
||||||
%% \input{planning.tex}
|
%% \input{planning.tex}
|
||||||
%% \input{halftime.tex}
|
%% \input{halftime.tex}
|
||||||
|
|
|
@ -198,7 +198,7 @@ module _ {ℓa ℓb : Level} (ℂ : Category ℓa ℓb) where
|
||||||
Req = Functor≡ rawEq
|
Req = Functor≡ rawEq
|
||||||
|
|
||||||
pureTEq : Monoidal.RawMonad.pureT (toMonoidalRaw (toKleisli m)) ≡ pureT
|
pureTEq : Monoidal.RawMonad.pureT (toMonoidalRaw (toKleisli m)) ≡ pureT
|
||||||
pureTEq = funExt (λ X → refl)
|
pureTEq = refl
|
||||||
|
|
||||||
pureNTEq : (λ i → NaturalTransformation Functors.identity (Req i))
|
pureNTEq : (λ i → NaturalTransformation Functors.identity (Req i))
|
||||||
[ Monoidal.RawMonad.pureNT (toMonoidalRaw (toKleisli m)) ≡ pureNT ]
|
[ Monoidal.RawMonad.pureNT (toMonoidalRaw (toKleisli m)) ≡ pureNT ]
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
{-
|
{-
|
||||||
This module provides construction 2.3 in [voe]
|
This module provides construction 2.3 in [voe]
|
||||||
-}
|
-}
|
||||||
{-# OPTIONS --cubical --allow-unsolved-metas #-}
|
{-# OPTIONS --cubical #-}
|
||||||
module Cat.Category.Monad.Voevodsky where
|
module Cat.Category.Monad.Voevodsky where
|
||||||
|
|
||||||
open import Cat.Prelude
|
open import Cat.Prelude
|
||||||
|
@ -152,7 +152,26 @@ module voe {ℓa ℓb : Level} (ℂ : Category ℓa ℓb) where
|
||||||
§2-fromMonad
|
§2-fromMonad
|
||||||
((Monoidal→Kleisli ∘ Kleisli→Monoidal)
|
((Monoidal→Kleisli ∘ Kleisli→Monoidal)
|
||||||
(§2-3.§2.toMonad m))
|
(§2-3.§2.toMonad m))
|
||||||
≡⟨ (cong-d (\ φ → §2-fromMonad (φ (§2-3.§2.toMonad m))) re-ve) ⟩
|
-- Below is the fully normalized goal and context with
|
||||||
|
-- `funExt` made abstract.
|
||||||
|
--
|
||||||
|
-- Goal: PathP (λ _ → §2-3.§2 omap (λ {z} → pure))
|
||||||
|
-- (§2-fromMonad
|
||||||
|
-- (.Cat.Category.Monad.toKleisli ℂ
|
||||||
|
-- (.Cat.Category.Monad.toMonoidal ℂ (§2-3.§2.toMonad m))))
|
||||||
|
-- (§2-fromMonad (§2-3.§2.toMonad m))
|
||||||
|
-- Have: PathP
|
||||||
|
-- (λ i →
|
||||||
|
-- §2-3.§2 K.IsMonad.omap
|
||||||
|
-- (K.RawMonad.pure
|
||||||
|
-- (K.Monad.raw
|
||||||
|
-- (funExt (λ m₁ → K.Monad≡ (.Cat.Category.Monad.toKleisliRawEq ℂ m₁))
|
||||||
|
-- i (§2-3.§2.toMonad m)))))
|
||||||
|
-- (§2-fromMonad
|
||||||
|
-- (.Cat.Category.Monad.toKleisli ℂ
|
||||||
|
-- (.Cat.Category.Monad.toMonoidal ℂ (§2-3.§2.toMonad m))))
|
||||||
|
-- (§2-fromMonad (§2-3.§2.toMonad m))
|
||||||
|
≡⟨ ( cong-d {x = Monoidal→Kleisli ∘ Kleisli→Monoidal} {y = idFun K.Monad} (\ φ → §2-fromMonad (φ (§2-3.§2.toMonad m))) re-ve) ⟩
|
||||||
(§2-fromMonad ∘ §2-3.§2.toMonad) m
|
(§2-fromMonad ∘ §2-3.§2.toMonad) m
|
||||||
≡⟨ lemma ⟩
|
≡⟨ lemma ⟩
|
||||||
m ∎
|
m ∎
|
||||||
|
@ -174,24 +193,41 @@ module voe {ℓa ℓb : Level} (ℂ : Category ℓa ℓb) where
|
||||||
§1-fromMonad
|
§1-fromMonad
|
||||||
((Kleisli→Monoidal ∘ Monoidal→Kleisli)
|
((Kleisli→Monoidal ∘ Monoidal→Kleisli)
|
||||||
(§2-3.§1.toMonad m))
|
(§2-3.§1.toMonad m))
|
||||||
|
-- Below is the fully normalized `agda2-goal-and-context`
|
||||||
|
-- with `funExt` made abstract.
|
||||||
|
--
|
||||||
|
-- Goal: PathP (λ _ → §2-3.§1 omap (λ {X} → pure))
|
||||||
|
-- (§1-fromMonad
|
||||||
|
-- (.Cat.Category.Monad.toMonoidal ℂ
|
||||||
|
-- (.Cat.Category.Monad.toKleisli ℂ (§2-3.§1.toMonad m))))
|
||||||
|
-- (§1-fromMonad (§2-3.§1.toMonad m))
|
||||||
|
-- Have: PathP
|
||||||
|
-- (λ i →
|
||||||
|
-- §2-3.§1
|
||||||
|
-- (RawFunctor.omap
|
||||||
|
-- (Functor.raw
|
||||||
|
-- (M.RawMonad.R
|
||||||
|
-- (M.Monad.raw
|
||||||
|
-- (funExt
|
||||||
|
-- (λ m₁ → M.Monad≡ (.Cat.Category.Monad.toMonoidalRawEq ℂ m₁)) i
|
||||||
|
-- (§2-3.§1.toMonad m))))))
|
||||||
|
-- (λ {X} →
|
||||||
|
-- fst
|
||||||
|
-- (M.RawMonad.pureNT
|
||||||
|
-- (M.Monad.raw
|
||||||
|
-- (funExt
|
||||||
|
-- (λ m₁ → M.Monad≡ (.Cat.Category.Monad.toMonoidalRawEq ℂ m₁)) i
|
||||||
|
-- (§2-3.§1.toMonad m))))
|
||||||
|
-- X))
|
||||||
|
-- (§1-fromMonad
|
||||||
|
-- (.Cat.Category.Monad.toMonoidal ℂ
|
||||||
|
-- (.Cat.Category.Monad.toKleisli ℂ (§2-3.§1.toMonad m))))
|
||||||
|
-- (§1-fromMonad (§2-3.§1.toMonad m))
|
||||||
≡⟨ (cong-d (\ φ → §1-fromMonad (φ (§2-3.§1.toMonad m))) ve-re) ⟩
|
≡⟨ (cong-d (\ φ → §1-fromMonad (φ (§2-3.§1.toMonad m))) ve-re) ⟩
|
||||||
§1-fromMonad (§2-3.§1.toMonad m)
|
§1-fromMonad (§2-3.§1.toMonad m)
|
||||||
≡⟨ lemmaz ⟩
|
≡⟨ lemmaz ⟩
|
||||||
m ∎
|
m ∎
|
||||||
where
|
where
|
||||||
-- having eta equality on causes roughly the same work as checking this proof of foo,
|
|
||||||
-- which is quite expensive because it ends up reducing complex terms.
|
|
||||||
|
|
||||||
-- rhs = §1-fromMonad (Kleisli→Monoidal ((Monoidal→Kleisli (§2-3.§1.toMonad m))))
|
|
||||||
-- foo : §1-fromMonad (Kleisli→Monoidal (§2-3.§2.toMonad (§2-fromMonad (Monoidal→Kleisli (§2-3.§1.toMonad m)))))
|
|
||||||
-- ≡ §1-fromMonad (Kleisli→Monoidal ((Monoidal→Kleisli (§2-3.§1.toMonad m))))
|
|
||||||
-- §2-3.§1.fmap (foo i) = §2-3.§1.fmap rhs
|
|
||||||
-- §2-3.§1.join (foo i) = §2-3.§1.join rhs
|
|
||||||
-- §2-3.§1.RisFunctor (foo i) = §2-3.§1.RisFunctor rhs
|
|
||||||
-- §2-3.§1.pureN (foo i) = §2-3.§1.pureN rhs
|
|
||||||
-- §2-3.§1.joinN (foo i) = §2-3.§1.joinN rhs
|
|
||||||
-- §2-3.§1.isMonad (foo i) = §2-3.§1.isMonad rhs
|
|
||||||
|
|
||||||
lemmaz : §1-fromMonad (§2-3.§1.toMonad m) ≡ m
|
lemmaz : §1-fromMonad (§2-3.§1.toMonad m) ≡ m
|
||||||
§2-3.§1.fmap (lemmaz i) = §2-3.§1.fmap m
|
§2-3.§1.fmap (lemmaz i) = §2-3.§1.fmap m
|
||||||
§2-3.§1.join (lemmaz i) = §2-3.§1.join m
|
§2-3.§1.join (lemmaz i) = §2-3.§1.join m
|
||||||
|
|
Loading…
Reference in a new issue