Changeset 3619


Ignore:
Timestamp:
Mar 6, 2017, 4:02:43 PM (8 weeks ago)
Author:
boender
Message:

Added section on Matita

Location:
Papers/jar-cerco-2017
Files:
3 edited

Legend:

Unmodified
Added
Removed
  • Papers/jar-cerco-2017/cerco.bib

    r3605 r3619  
    291291  key = {jessie}
    292292}
     293
     294@article
     295{ asperti:user:2007,
     296  author = {Andrea Asperti and Claudio {Sacerdoti Coen} and Enrico Tassi and Stefano Zacchiroli},
     297  title = {User interaction with the {Matita} proof assistant},
     298  journal = {Automated Reasoning},
     299  pages = {109--139},
     300  volume = {39},
     301  issue = {2},
     302  year = {2007}
     303}
     304
     305@article
     306{ sacerdoti-coen:tinycals:2007,
     307  author = {Claudio Sacerdoti Coen and Enrico Tassi and Stefano Zacchiroli},
     308  title = {{Tinycals}: Step by Step Tacticals},
     309  journal = {Electronic Notes in Theoretical Computer Science},
     310  volume = {174},
     311  number = {2},
     312  pages = {125--142},
     313  doi = {http://dx.doi.org/10.1016/j.entcs.2006.09.026},
     314  year = {2007}
     315}
     316
     317@incollection
     318{ sozeau:subset:2007,
     319  author = {Matthieu Sozeau},
     320  title = {Subset Coercions in {Coq}},
     321  booktitle = {Types for Proofs and Programs},
     322  volume = {4502},
     323  series = {Lecture Notes in Computer Science},
     324  doi = {10.1007/978-3-540-74464-1_16},
     325  pages = {237--252},
     326  year = {2007}
     327}
     328
     329@inproceedings
     330{ asperti:higher-order:2007,
     331  author = {Andrea Asperti and Enrico Tassi},
     332  title = {Higher order Proof Reconstruction from Paramodulation-Based Refutations: The Unit Equality Case},
     333  booktitle = {Towards Mechanized Mathematical Assistants: Calculemus},
     334  pages = {146--160},
     335  series = {Lecture Notes in Computer Science},
     336  volume = {4573},
     337  year = 2007
     338}
     339
     340@inproceedings
     341{ bove:brief:2009,
     342  author = {Ana Bove and Peter Dybjer and Ulf Norell},
     343  title = {A Brief Overview of {Agda} --- A Functional Language with Dependent Types},
     344  booktitle = {Theorem Proving in Higher-order Logics {(TPHOLs)}},
     345  year = {2009}
     346}
     347
     348@manual
     349{ coq:2004,
     350  title = {The {Coq} proof assistant reference manual},
     351  author =  {{The Coq development team}},
     352  organization = {{LogiCal Project}},
     353  note = {Version 8.0},
     354  year = {2004},
     355  url = {http://coq.inria.fr}
     356}
     357
     358@misc
     359{ cerco:2011,
     360  title = {The {CerCo} {FET-Open} project},
     361  howpublished = {\url{http://cerco.cs.unibo.it/}},
     362  year = {2011},
     363  key = {CerCo:2011}
     364}
  • Papers/jar-cerco-2017/cerco.tex

    r3615 r3619  
    4646
    4747\lstset{language=C,basicstyle=\tt,basewidth=.5em,lineskip=-1.5pt}
     48\def\lstlanguagefiles{lst-grafite.tex}
    4849
    4950\newlength{\mylength}
  • Papers/jar-cerco-2017/introduction.tex

    r3618 r3619  
     1\newcommand{\All}[1]{\forall{#1}.\;}
     2\newcommand{\lam}[1]{\lambda{#1}.\;}
     3
    14% Introduction
    25%   Problem being solved, background, etc.
     
    273276\subsection{Introduction to Matita}
    274277
    275 The theorem prover used to implement and verify the prototype compiler is
    276 Matita~\cite{matita}.
    277 
    278 Matita, like Coq, is based on the Calculus of (Co)Inductive Constructions. Its
    279 main features are:
    280 
     278Matita is a theorem prover based on a variant of the Calculus of Coinductive Constructions~\cite{asperti:user:2007}.
     279The system features a full spectrum of dependent types and (co)inductive families, a system of coercions, a tactic-driven proof construction engine~\cite{sacerdoti-coen:tinycals:2007}, and paramodulation based automation~\cite{asperti:higher-order:2007}, all of which we exploit in the formalisation described herein.
     280
     281Matita's syntax is similar to the syntaxes of mainstream functional programming languages such as OCaml or Standard ML.
     282The type theory that Matita implements is broadly akin to that of Coq~\cite{coq:2004} and Agda~\cite{bove:brief:2009}.
     283Nevertheless, we provide a brief explanation of the main syntactic and type-theoretic features of Matita that will be needed to follow the body of the paper:
    281284\begin{itemize}
    282         \item A bidirectional type inference algorithm, which combines usage of
    283         inferred and expected types. The type inference algorithm also uses a hints
    284         system that helps with unification;
    285         \item A disambiguation system that allows for notation overloading by having
    286         the parser and typechecker cooperate closely.
     285\item
     286Non-recursive functions and definitions are introduced via the \texttt{definition} keyword.
     287Recursive functions are introduced with \texttt{let rec}.
     288Mutually recursive functions are separated via the \texttt{and} keyword.
     289Matita's termination checker ensures that all recursive functions are terminating before being admitted to maintain soundness of the system's logic.
     290\item
     291Matita has an infinite hierarchy of type universes.
     292A single impredicative universe of types, \texttt{Prop}, exists at the base of this hierarchy.
     293An infinite series of predicative universes, \texttt{Type[0]} : \texttt{Type[1]} : \texttt{Type[2]}, and so on and so forth, sits atop \texttt{Prop}.
     294Matita, unlike Coq or Agda, implements no form of typical ambiguity or universe polymorphism, with explicit concrete universe levels being preferred instead.
     295\item
     296Matita's type theory plays host to a rich and expressive higher-order logic.
     297Constants \texttt{True} and \texttt{False} represent truth and falsity in \texttt{Prop} respectively.
     298Two inductive families in \texttt{Prop} encode conjunction and disjunction---$\mathtt{P \wedge Q}$ and $\mathtt{P \vee Q}$ respectively.
     299
     300As is usual, implication and universal quantification are identified with the dependent function space ($\Pi$ types), whereas (constructive) existential quantification is encoded as a dependent sum (a $\Sigma$-type).
     301We write $\All{x : \phi}\psi$ for the dependent function space, and abbreviate this as $\phi \rightarrow \psi$ when $x \not\in fv(\psi)$ as usual.
     302We use $\langle M,N \rangle$ for the pairing of $M$ and $N$.
     303\item
     304Inductive and coinductive families are introduced via the \texttt{inductive} and \texttt{coinductive} keywords respectively, with named constructor declarations separated by a bar.
     305Mutually inductive data family declarations are separated via \texttt{with}.
     306In the following declaration:
     307\begin{lstlisting}[language=Grafite]
     308inductive I ($P_1$ : $\tau_1$) $\ldots$ ($P_n$ : $\tau_n$) : $\phi_1 \rightarrow \ldots \rightarrow \phi_m \rightarrow \phi$ := $\ldots$
     309\end{lstlisting}
     310We call $P_i$ for $0 \leq i \leq n$ the \textbf{parameters} of \texttt{I} and $\phi_j$ for $0 \leq j \leq m$ the \textbf{indices} of \texttt{I}.
     311Matita's positivity checker ensures that constructors have strictly-positive types before admitting an inductive family to maintain soundness of the system's logic.
     312\item
     313Records are introduced with the \texttt{record} keyword.
     314A Matita record
     315\begin{lstlisting}[language=Grafite]
     316record R : Type[0] := { F1 : nat }.
     317\end{lstlisting}
     318may be thought of as syntactic sugar for a single-constructor inductive data type of the same name:
     319\begin{lstlisting}[language=Grafite]
     320inductive R : Type[0] :=
     321  | mk_R : nat -> R.
     322\end{lstlisting}
     323A record field's type may depend on fields declared earlier in the record.
     324
     325Records may be decomposed with projections.
     326Projections, one for each of field of a record, are registered in the global context.
     327In the example record above, \texttt{F1} of type $R \rightarrow nat$ is registered as a field projection and $mk\_R$ of type $nat \rightarrow R$ is registered as a constructor.
     328
     329Record fields may also be marked as coercions.
     330In the following example
     331\begin{lstlisting}[language=Grafite]
     332record S : Type[1] :=
     333{
     334  Carrier :> Type[0];
     335  op : Carrier -> Carrier -> Carrier
     336}
     337\end{lstlisting}
     338the field \texttt{Carrier} is declared to be a coercion with `\texttt{:>}'.with the operational effect being that the field projection \texttt{Carrier} may be omitted where it could be successfully inferred by Matita.
     339Field coercions facilitate the informal but common mathematical practice of intentionally confusing a structure with its underlying carrier set.
     340\item
     341Terms may be freely omitted, allowing the user to write down partial types and terms.
     342A question mark, \texttt{?}, denotes a single term that has been omitted by the user.
     343Some omitted terms can be deduced by Matita's refinement system.
     344Other, more complex goals arising from omitted terms may require user input to solve, in which case a proof obligation is opened for each term that cannot be deduced automatically.
     345Three consecutive dots, \texttt{$\ldots$}, denote multiple terms or types that have been omitted.
     346\item
     347Data may be decomposed by pattern matching with a \texttt{match} expression.
     348We may fully annotate a \texttt{match} expression with its return type.
     349This is especially useful when working with indexed families of types or with invariants, expressed as types, on functions.
     350In the following
     351\begin{lstlisting}[language=Grafite]
     352match t return $\lam{x}x = 0 \rightarrow bool$ with
     353[ 0    $\Rightarrow$ $\lam{prf_1}P_1$
     354| S m $\Rightarrow$ $\lam{prf_2}P_2$
     355] (refl $\ldots$ t)
     356\end{lstlisting}
     357the \texttt{0} branch of the \texttt{match} expression returns a function from $0 = 0$ to \texttt{bool}, whereas the \texttt{S m} branch of the \texttt{match} expression returns a function from \texttt{S m = 0} to \texttt{bool}.
     358In both cases the annotated return type $\lam{x}x = 0 \rightarrow bool$ has been specialised given new information about \texttt{t} revealed by the act of pattern matching.
     359The entire term, with \texttt{match} expression applied to \texttt{refl $\ldots$ t}, has type \texttt{bool}.
     360\item
     361Matita features a liberal system of coercions (distinct from the previously mentioned record field coercions).
     362It is possible to define a uniform coercion $\lam{x}\langle x, ?\rangle$ from every type $T$ to the dependent product $\Sigma{x : T}. P x$.
     363The coercion opens a proof obligation that asks the user to prove that $P$ holds for $x$.
     364When a coercion is to be applied to a complex term (for example, a $\lambda$-abstraction, a local definition, or a case analysis), the system automatically propagates the coercion to the sub-terms.
     365For instance, to apply a coercion to force $\lam{x}M : A \rightarrow B$ to
     366have type $\All{x : A}\Sigma{y : B}. P x y$, the system looks for a coercion from $M : B$ to $\Sigma{y : B}. P x y$ in a context augmented with $x : A$.
     367This is significant when the coercion opens a proof obligation, as the user will be presented with multiple, but simpler proof obligations in the correct context.
     368In this way, Matita supports the `Russell' proof methodology developed by Sozeau in~\cite{sozeau:subset:2007}, in a lightweight but tightly-integrated manner.
    287369\end{itemize}
     370Throughout, for reasons of clarity, conciseness, and readability, we may choose to simplify or omit parts of Matita code.
     371We will always ensure that these omissions do not mislead the reader.
    288372
    289373\subsection{Map of the paper}
     
    305389some of the case studies we have performed to validate it.
    306390
    307 Finally, in section~\ref{sect:conclusions} we present conclusions, as well as
     391Finally, in section~\ref{sect.conclusions} we present conclusions, as well as
    308392related and future work.
Note: See TracChangeset for help on using the changeset viewer.