\newcommand{\components}{components}
\newcommand{\AUTO}{\textsc{Auto}}
+\newcommand{\BOXML}{BoxML}
\newcommand{\COQ}{Coq}
+\newcommand{\COQIDE}{CoqIde}
\newcommand{\ELIM}{\textsc{Elim}}
\newcommand{\GDOME}{Gdome}
+\newcommand{\GTKMATHVIEW}{\textsc{GtkMathView}}
\newcommand{\HELM}{Helm}
\newcommand{\HINT}{\textsc{Hint}}
\newcommand{\IN}{\ensuremath{\dN}}
\newcommand{\LIBXSLT}{LibXSLT}
\newcommand{\LOCATE}{\textsc{Locate}}
\newcommand{\MATCH}{\textsc{Match}}
+\newcommand{\MATHML}{MathML}
\newcommand{\MATITA}{Matita}
+\newcommand{\MATITAC}{\texttt{matitac}}
+\newcommand{\MATITADEP}{\texttt{matitadep}}
\newcommand{\METAHEADING}{Symbol & Position \\ \hline\hline}
\newcommand{\MOWGLI}{MoWGLI}
\newcommand{\NAT}{\ensuremath{\mathit{nat}}}
\newcommand{\URI}[1]{\texttt{#1}}
\newcommand{\OP}[1]{``\texttt{#1}''}
-%{\end{SaveVerbatim}\setlength{\fboxrule}{.5mm}\setlength{\fboxsep}{2mm}%
\newenvironment{grafite}{\VerbatimEnvironment
\begin{SaveVerbatim}{boxtmp}}%
{\end{SaveVerbatim}\setlength{\fboxsep}{3mm}%
{}
\newcommand{\ASSIGNEDTO}[1]{\textbf{Assigned to:} #1}
\newcommand{\FILE}[1]{\texttt{#1}}
-% \newcommand{\NOTE}[1]{\ifodd \arabic{page} \else \hspace{-2cm}\fi\ednote{#1}}
-\newcommand{\NOTE}[1]{\ednote{#1}{foo}}
+\newcommand{\NOTE}[1]{\ednote{#1}{}}
\newcommand{\TODO}[1]{\textbf{TODO: #1}}
\newcounter{pass}
\institute{Department of Computer Science, University of Bologna\\
Mura Anteo Zamboni, 7 --- 40127 Bologna, ITALY}
-\runningtitle{The Matita proof assistant}
+\runningtitle{The \MATITA{} proof assistant}
\runningauthor{Asperti, Sacerdoti Coen, Tassi, Zacchiroli}
% \date{data}
\end{opening}
+\tableofcontents
\section{Introduction}
\label{sec:intro}
%search engine, described in~\cite{whelp};
\item developing languages and tools for a high-quality notational
rendering of mathematical information\footnote{We have been
-active in the MathML Working group since 1999.};
+active in the \MATHML{} Working group since 1999.};
%and developed inside
-%\HELM{} a MathML-compliant widget for the GTK graphical environment
+%\HELM{} a \MATHML-compliant widget for the GTK graphical environment
%which can be integrated in any application.
\end{itemize}
According to our content-centric commitment, the library exported from
-Coq was conceived as being distributed and most of the tools were developed
+\COQ{} was conceived as being distributed and most of the tools were developed
as Web services. The user could interact with the library and the tools by
means of a Web interface that orchestrates the Web services.
The Web services and the other tools have been implemented as front-ends
-to a set of software libraries, collectively called the \HELM{} libraries.
+to a set of software components, collectively called the \HELM{} components.
At the end of the \MOWGLI{} project we already disposed of the following
-tools and software libraries:
+tools and software components:
\begin{itemize}
\item XML specifications for the Calculus of Inductive Constructions,
-with libraries for parsing and saving mathematical objects in such a format
+with components for parsing and saving mathematical objects in such a format
\cite{exportation-module};
-\item metadata specifications with libraries for indexing and querying the
+\item metadata specifications with components for indexing and querying the
XML knowledge base;
\item a proof checker library (i.e. the {\em kernel} of a proof assistant),
-implemented to check that we exported form the \COQ{} library all the
+implemented to check that we exported from the \COQ{} library all the
logically relevant content;
\item a sophisticated parser (used by the search engine), able to deal
with potentially ambiguous and incomplete information, typical of the
partially specified terms, used by the disambiguating parser;
\item complex transformation algorithms for proof rendering in natural
language \cite{remathematization};
-\item an innovative, MathML-compliant rendering widget for the GTK
+\item an innovative, \MATHML-compliant rendering widget for the GTK
graphical environment\cite{padovani}, supporting
high-quality bidimensional
rendering, and semantic selection, i.e. the possibility to select semantically
-meaningful rendering expressions, and to past the respective content into
+meaningful rendering expressions, and to paste the respective content into
a different text area.
\end{itemize}
Starting from all this, developing our own proof assistant was not
overall management of the library, integrating everything into a
single system. \MATITA{} is the result of this effort.
-\subsection{The System}
-DESCRIZIONE DEL SISTEMA DAL PUNTO DI VISTA ``UTENTE''
+\subsection{The system}
+
+\MATITA{} is a proof assistant (also called interactive theorem prover).
+It is based on the Calculus of (Co)Inductive Constructions (CIC) that
+is a dependently typed lambda-calculus \`a la Church enriched with primitive
+inductive and co-indutive data types. Via the Curry-Howard isomorphism, the
+calculus can be seen as a very rich higher order logic and proofs can be
+simply represented and stored as lambda-terms. Coq and Lego are other systems
+that adopt (variations of) CIC as their foundation.
+
+The proof language of \MATITA{} is procedural, in the tradition of the LCF
+theorem prover. Coq, NuPRL, PVS, Isabelle are all examples of others systems
+whose proof language is procedural. Traditionally, in a procedural system
+the user interacts only with the \emph{script}, while proof terms are internal
+records kept by the system. On the contrary, in \MATITA{} proof terms are
+praised as declarative versions of the proof. With this role, they are the
+primary mean of communication of proofs (once rendered to natural language
+for human audiences).
+
+The user interfaces now adopted by all the proof assistants that adopt a
+procedural proof language have been inspired by the CtCoq pioneering
+system~\cite{ctcoq}. One succesfull incarnation of the ideas introduced
+by CtCoq is the Proof General generic interface, that has set a sort of
+standard way to interact with the system. Several procedural proof assistants
+have either adopted or cloned Proof General as their main user interface.
+\MATITA{} has also cloned the Proof General interface,
\begin{itemize}
\item scelta del sistema fondazionale
- \item sistema indipendente (da Coq)
+ \item sistema indipendente (da \COQ)
\item compatibilit\`a con sistemi legacy
\end{itemize}
we could furtherly reduce our code in sensible way).
Moreover, the complexity of the code of \MATITA{} is greatly reduced with
-respect to \COQ. For instance, the API of the libraries of \MATITA{} comprise
+respect to \COQ. For instance, the API of the components of \MATITA{} comprise
989 functions, to be compared with the 4'286 functions of \COQ.
Finally, \MATITA{} has several innovatives features over \COQ{} that derive
we have took advantage of the research results and experiences previously
developed by others, comprising the authors of \COQ. Moreover, starting from
scratch, we have designed in advance the architecture and we have splitted
-the code in coherent minimally coupled libraries.
+the code in coherent minimally coupled components.
In the future we plan to exploit \MATITA{} as a test bench for new ideas and
-extensions. Keeping the single libraries and the whole architecture as
+extensions. Keeping the single components and the whole architecture as
simple as possible is thus crucial to foster future experiments and to
allow other developers to quickly understand our code and contribute.
%be able to contribute to \COQ{}'s code is quite steep and requires direct
%and frequent interactions with \COQ{} developers.
-\begin{figure}[t]
+\section{Architecture}
+\label{architettura}
+
+\begin{figure}[ht]
\begin{center}
\includegraphics[width=0.9\textwidth]{librariesCluster.ps}
- \caption{\MATITA{} libraries}
+ \caption{\MATITA{} components}
\label{fig:libraries}
\end{center}
\end{figure}
-\section{Architecture}
-\label{architettura}
Fig.~\ref{fig:libraries} shows the architecture of the \emph{\components}
(circle nodes) and \emph{applications} (squared nodes) developed in the HELM
project.
For those \components{} whose functionalities are also provided by the
aforementioned Web services, it is also possible to link stub code that
forwards the request to a remote Web service. For instance, the Getter
-is just a wrapper to the \texttt{getter} \component{} that allows the
+is just a wrapper to the \GETTER \component{} that allows the
\component{} to be used as a Web service. \MATITA{} can directly link the code
-of the \texttt{getter} \component, or it can use a stub library with the same
+of the \GETTER \component, or it can use a stub library with the same
API that forwards every request to the Getter.
To better understand the architecture of \MATITA{} and the role of each
\component, we can focus on the representation of the mathematical information.
\MATITA{} is based on (a variant of) the Calculus of (Co)Inductive
Constructions (CIC). In CIC terms are used to represent mathematical
-expressions, types and proofs. \MATITA{} is able to handle terms at
+formulae, types and proofs. \MATITA{} is able to handle terms at
four different levels of specification. On each level it is possible to provide
a different set of functionalities. The four different levels are:
fully specified terms; partially specified terms;
Terms may reference other mathematical notions in the library.
One commitment of our project is that the library should be physically
- distributed. The \texttt{getter} \component{} manages the distribution,
+ distributed. The \GETTER \component{} manages the distribution,
providing a mapping from logical names (URIs) to the physical location
of a notion (an URL). The \texttt{urimanager} \component{} provides the URI
data type and several utility functions over URIs. The
- \texttt{cic\_proof\_checking} \component{} calls the \texttt{getter}
+ \texttt{cic\_proof\_checking} \component{} calls the \GETTER
\component{} every time it needs to retrieve the definition of a mathematical
notion referenced by a term that is being type-checked.
We use metadata and a sort of crawler to index the mathematical notions
in the distributed library. We are interested in retrieving a notion
by matching, instantiation or generalization of a user or system provided
- mathematical expression. Thus we need to collect metadata over the fully
+ mathematical formula. Thus we need to collect metadata over the fully
specified terms and to store the metadata in some kind of (relational)
database for later usage. The \texttt{hmysql} \component{} provides
a simplified
of preserving the coherence of the library and the database. For instance,
when a notion is removed, all the notions that depend on it and their
metadata are removed from the library. This aspect will be better detailed
- in Sect.~\ref{decompilazione}.
+ in Sect.~\ref{sec:libmanagement}.
\subsection{Partially specified terms}
\emph{Partially specified terms} are CIC terms where subterms can be omitted.
given by the conclusion of the sequent. The term must be closed in the
context that is given by the ordered list of hypotheses of the sequent.
The explicit substitution instantiates every hypothesis with an actual
-value for the term bound by the hypothesis.
+value for the variable bound by the hypothesis.
Partially specified terms are not required to be well-typed. However a
partially specified term should be \emph{refinable}. A \emph{refiner} is
a type-inference procedure that can instantiate implicit terms and
metavariables and that can introduce \emph{implicit coercions} to make a
-partially specified term be well-typed. The refiner of \MATITA{} is implemented
+partially specified term well-typed. The refiner of \MATITA{} is implemented
in the \texttt{cic\_unification} \component. As the type checker is based on
the conversion check, the refiner is based on \emph{unification} that is
a procedure that makes two partially specified term convertible by instantiating
and lemmas. The \texttt{grafite\_engine} \component{} is the core of \MATITA{}.
It implements the semantics of each command in the grafite AST as a function
from status to status. It implements also an undo function to go back to
-previous statuses. \TODO{parlare di disambiguazione lazy \& co?}
+previous statuses.
As fully specified terms, partially specified terms are not well suited
for user consumption since their syntax is not extendible and it is not
\subsection{Content level terms}
\label{sec:contentintro}
-The language used to communicate proofs and expecially expressions with the
+The language used to communicate proofs and expecially formulae with the
user does not only needs to be extendible and accomodate the usual mathematical
notation. It must also reflect the comfortable degree of imprecision and
ambiguity that the mathematical language provides.
to communicate formulae with the user and with external tools, it seems good
practice to stick to the usual imprecise mathematical ontology. In the
Mathematical Knowledge Management community this imprecise language is called
-the \emph{content level} representation of expressions.
+the \emph{content level} representation of formulae.
In \MATITA{} we provide two translations: from partially specified terms
to content level terms and the other way around. The first translation can also
The translation from partially specified terms to content level terms must
discriminate between terms used to represent proofs and terms used to represent
-expressions. The firsts are translated to a content level representation of
-proof steps that can easily be rendered in natural language. The latters
-are translated to MathML Content formulae. MathML Content~\cite{mathml} is a W3C
-standard
-for the representation of content level expressions in an XML extensible format.
+formulae. The firsts are translated to a content level representation of
+proof steps that can easily be rendered in natural language. The representation
+adopted has greatly influenced the OMDoc~\cite{omdoc} proof format that is now
+isomorphic to it. Terms that represent formulae are translated to \MATHML{}
+Content formulae. \MATHML{} Content~\cite{mathml} is a W3C standard
+for the representation of content level formulae in an XML extensible format.
The translation to content level is implemented in the
\texttt{acic\_content} \component. Its input are \emph{annotated partially
specified terms}, that are maximally unshared
partially specified terms enriched with additional typing information for each
subterm. This information is used to discriminate between terms that represent
-proofs and terms that represent expressions. Part of it is also stored at the
+proofs and terms that represent formulae. Part of it is also stored at the
content level since it is required to generate the natural language rendering
of proofs. The terms need to be maximally unshared (i.e. they must be a tree
and not a DAG). The reason is that to the occurrences of a subterm in
We do not provide yet a reverse translation from content level proofs to
partially specified terms. But in \texttt{cic\_disambiguation} we do provide
-the reverse translation for expressions. The mapping from
-content level expressions to partially specified terms is not unique due to
+the reverse translation for formulae. The mapping from
+content level formulae to partially specified terms is not unique due to
the ambiguity of the content level. As a consequence the translation
is guided by an \emph{interpretation}, that is a function that chooses for
-every ambiguous expression one partially specified term. The
+every ambiguous formula one partially specified term. The
\texttt{cic\_disambiguation} \component{} implements the
disambiguation algorithm we presented in~\cite{disambiguation} that is
responsible of building in an efficicent way the set of all ``correct''
interpretations. An interpretation is correct if the partially specified term
obtained using the interpretation is refinable.
+In the last section we have described the semantics of a command as a
+function from status to status. We also suggested that the formulae in a
+command are encoded as partially specified terms. However, consider the
+command ``\texttt{replace} $x$ \texttt{with} $y^2$''. Until the occurrence
+of $x$ to be replaced is located, its context is unknown. Since $y^2$ must
+replace $x$ in that context, its encoding as a term cannot be computed
+until $x$ is located. In other words, $y^2$ must be disambiguated in the
+context of the occurrence $x$ it must replace.
+
+The elegant solution we have implemented consists in representing terms
+in a command as function from a context to a partially refined term. The
+function is obtained by partially applying our disambiguation function to
+the content term to be disambiguated. Our solution should be compared with
+the one adopted in the Coq system (where ambiguity is only relative to
+DeBrujin indexes). In Coq variables can be bound either by name or by
+position. This makes more complex every operation over terms (i.e. according
+to our architecture every module that depends on \texttt{cic}). Moreover,
+this solution cannot cope with other forms of ambiguity (as the meaning
+of the $~^2$ exponent in the previous example that depends on the context).
+
\subsection{Presentation level terms}
Content level terms are a sort of abstract syntax trees for mathematical
-expressions and proofs. The concrete syntax given to these abstract trees
+formulae and proofs. The concrete syntax given to these abstract trees
is called \emph{presentation level}.
The main important difference between the content level language and the
single day, but they stick to a set of symbols that is more or less fixed.
The fact that the presentation language is finite allows the definition of
-standard languages. In particular, for formulae we have adopt MathML
+standard languages. In particular, for formulae we have adopt \MATHML{}
Presentation~\cite{mathml} that is an XML dialect standardized by the W3C. To
visually
represent proofs it is enough to embed formulae in plain text enriched with
formatting boxes. Since the language of formatting boxes is very simple,
many equivalent specifications exist and we have adopted our own, called
-BoxML.
+\BOXML.
The \texttt{content\_pres} \component{} contains the implementation of the
translation from content level terms to presentation level terms. The
rendering of presentation level terms is left to the application that uses
the \component. However, in the \texttt{hgdome} \component{} we provide a few
-utility functions to build a \GDOME~\cite{gdome2} MathML+BoxML tree from our
+utility functions to build a \GDOME~\cite{gdome2} \MATHML+\BOXML{} tree from our
presentation
-level terms. \GDOME{} MathML+BoxML trees can be rendered by the GtkMathView
+level terms. \GDOME{} \MATHML+\BOXML{} trees can be rendered by the
+\GTKMATHVIEW{}
widget developed by Luca Padovani \cite{padovani}. The widget is
particularly interesting since it allows to implement \emph{semantic
selection}.
semantics of these commands. It also implements undoing of the semantic
actions. Among the commands there are hints to the
disambiguation algorithm that are used to control and speed up disambiguation.
-These mechanisms will be further discussed in Sect.~\ref{disambiguazione}.
+These mechanisms will be further discussed in Sect.~\ref{sec:disambiguation}.
Finally, the \texttt{grafite\_parser} \component{} implements a parser for
the concrete syntax of the commands of \MATITA. The parser process a stream
\texttt{logger}, \texttt{registry} and \texttt{utf8\_macros}) are
minor \components{} that provide a core of useful functions and basic
services missing from the standard library of the programming language.
-In particular, the \texttt{xml} \component{} is used
-to easily represent, parse and pretty-print XML files.
-
-\section{Using \MATITA (boh \ldots cambiare titolo)}
-
-\begin{figure}[t]
- \begin{center}
-% \includegraphics[width=0.9\textwidth]{a.eps}
- \caption{\MATITA{} screenshot}
- \label{fig:screenshot}
- \end{center}
-\end{figure}
+%In particular, the \texttt{xml} \component{} is used to easily represent,
+%parse and pretty-print XML files.
+
+
+\section{The interface to the library}
+
+A proof assistant provides both an interface to interact with its library and
+an \emph{authoring} interface to develop new proofs and theories. According
+to its historical origins, \MATITA{} strives to provide innovative
+functionalities for the interaction with the library. It is more traditional
+in its script based authoring interface.
+
+In the remaining part of the paper we focus on the user view of \MATITA{}.
+This section is devoted to the aspects of the tool that arise from the
+document centric approach to the library. Sect.~\ref{authoring} describes
+the peculiarities of the authoring interface.
+
+
+The library of \MATITA{} comprises mathematical concepts (theorems,
+axioms, definitions) and notation. The concepts are authored sequentially
+using scripts that are (ordered) sequences of procedural commands.
+However, once they are produced we store them independently in the library.
+The only relation implicitly kept between the notions are the logical,
+acyclic dependencies among them. This way the library forms a global (and
+distributed) hypertext. Several useful operations can be implemented on the
+library only, regardless of the scripts. Examples of such operations
+implemented in \MATITA{} are: searching and browing (see Sect.~\ref{sec:index});
+disambiguation of content level terms (see Sect.~\ref{sec:disambiguation});
+automatic proof searching (see Sect.~\ref{sec:automation}).
+
+A requisite for the previous operations is that the library must
+be fully accessible and in a logically consistent state. To preserve
+consistency, a concept cannot be altered or removed unless the part of the
+library that depends on it is modified accordingly. To allow incremental
+changes and cooperative development, consistent revisions are necessary.
+For instance, to modify a definition, the user could fork a new version
+of the library where the definition is updated and all the concepts that
+used to rely on it are absent. The user is then responsible to restore
+the removed part in the new branch, merging the branch when the library is
+fully restored.
+
+To implement the proposed versioning system on top of a standard one
+it is necessary to implement \emph{invalidation} first. Invalidation
+is the operation that locates and removes from the library all the concepts
+that depend on a given one. As described in Sect.~\ref{sec:...}, removing
+a concept from the library also involves deleting its metadata from the
+database.
+
+For non collaborative development, full versioning can be avoided, but
+invalidation is still required. Since nobody else is relying on your
+development, you are free to change and invalidate part of the library
+without branching. Invalidation is still necessary to avoid using a
+concept that is no longer valid.
+So far, in \MATITA{} we address only this non collaborative scenario
+(see Sect.~\ref{sec:decompilazione}). Collaborative development and versioning
+is still under design.
+
+Scripts are not seen as constituents of the library. They are not published
+and indexed, so they cannot be searched or browsed using \HELM{} tools.
+However, they play a central role for the mainteinance of the library.
+Indeed, once a notion is invalidated, the only way to restore it is to
+fix the possibly broken script that used to generate it.
+Moreover, during the authoring phase, scripts are a natural way to
+group notions together. They also constitute a less fine grained clustering
+of notions for invalidation.
+
+In the following sections we present in more details the functionalities
+of \MATITA{} related to library management and exploitation.
-\MATITA{} has a script based user interface. As can be seen in Fig.~... it is
-split in two main windows: on the left a textual widget is used to edit the
-script, on the right the list of open goal is shown using a MathML rendering
-widget. A distinguished part of the script (shaded in the screenshot) represent
-the commands already executed and can't be edited without undoing them. The
-remaining part can be freely edited and commands from that part can be executed
-moving down the execution point. An additional window --- the ``cicBrowser'' ---
-can be used to browse the library, including the proof being developed, and
-enable content based search on it. In the cicBrowser proofs are rendered in
-natural language, automatically generated from the low-level $\lambda$-terms
-using techniques inspired by \cite{natural,YANNTHESIS}.
-In the \MATITA{} philosophy the script is not relevant \emph{per se}, but is
-only seen as a convenient way to create mathematical objects. The universe of
-all these objects makes up the \HELM{} library, which is always completely
-visible to the user. The mathematical library is thus conceived as a global
-hypertext, where objects may freely reference each other. It is a duty of
-the system to guide the user through the relevant parts of the library.
-
-This methodological assumption has many important consequences
-which will be discussed in the next section.
-
-%on one side
-%it requires functionalities for the overall management of the library,
-%%%%%comprising efficient indexing techniques to retrieve and filter the
-%information;
-%on the other it introduces overloading in the use of
-%identifiers and mathematical notation, requiring sophisticated disambiguation
-%techniques for interpreting the user inputs.
-%In the next two sections we shall separately discuss the two previous
-%points.
-
-%In order to maximize accessibility mathematical objects are encoded in XML. (As%discussed in the introduction,) the modular architecture of \MATITA{} is
-%organized in components which work on data in this format. For instance the
-%rendering engine, which transform $\lambda$-terms encoded as XML document to
-%MathML Presentation documents, can be used apart from \MATITA{} to print ...
-%FINIRE
-
-A final section is devoted to some innovative aspects
-of the authoring system, such as a step by step tactical execution,
-content selection and copy-paste.
-
-\section{Library Management}
\subsection{Indexing and searching}
-
-\subsection{Compilation and decompilation}
-\label{compilazione}
-
-The aim of this section is to describe the way matita
-preserves the consistency and the availability of the library
-trough the \WHELP{} technology, in response to the user addition or
-deletion of mathematical objects.
-
-As already sketched in \ref{fully-spec} the output of the
-compilation of a script is split among two storage media, a
-classical filesystem and a relational database. The former is used to
-store the XML encoding of the objects defined in the script, the
-disambiguation aliases and the interpretation and notational convention defined,
-while the latter is used to store all the metadata needed by
-\WHELP{}. In addition the \emph{getter} component
-should be updated with the the new mapping between the logical URI
-and the physical path of objects.
-
-While this kind of consistency has nothing to do with the nature of
-the content of the library and is thus of poor interest (but really
-tedious to implement and keep bug-free), there is a more deep
-notion of mathematical consistency we need to provide. Each object
-must reference only defined object (i.e. each proof must use only
-already proved theorems).
-
-We will focus on how matita ensures the interesting kind
-of consistency during the formalization of a mathematical theory,
-giving the user the freedom of adding, deleting, modifying objects
-without loosing the feeling of an always visible and browsable
-library.
-
-\subsubsection{Compilation}
-The typechecker component guarantees that if an object is well typed
-it depends only on well defined objects available in the library,
-that is exactly what we need to be sure that the logic consistency of
-the library is preserved. We have only find the right order of
-compilation of the scripts that compose the user development.
-
-For this purpose we developed a low level tool called \emph{matitadep}
-that takes in input the list of files that compose the development and
-outputs their dependencies in a format suitable for the make utility.
-The user is not asked to run \emph{matitadep} nor make by hand, but
-simply to tell matita the root directory of his development (where all
-script files can be found) and matita will handle all the compilation
-tasks.\\
-To calculate dependencies it is enough to look at the script file for
-its inclusions of other parts of the development or for explicit
-references to other objects (i.e. with explicit aliases, see
-\ref{aliases}).
-
-The output of the compilation is immediately available to the user
-trough the \WHELP{} technology, since all metadata are stored in a
-user-specific area of the database where the search engine has read
-access, and all the automated tactics that operates on the whole
-library, like auto, have full visibility of the newly defined objects.
-
-Compilation is rather simple, and the only tricky case is when we want
-to compile again the same script, maybe after the deletion of a
-theorem. Here the policy is simple: decompile it before recompiling.
-As we will see in the next section decompilation will ensure that
-there will be no theorems in the development that depends on the
-removed item.
-
-\subsubsection{Decompilation}
-Decompiling an object involves,
-recursively, the decompilation of all the objects that depend on it.
-
-The calculation of the reverse dependencies can be computed in two
-ways, using the relational database or using a simpler set of metadata
-that matita saves in the filesystem as a result of compilation. The
-former technique is the same used by the \emph{Dependency Analyzer}
-described in \cite{zack-master} and really depends on a relational
-database.\\
-The latter is a fall-back in case the database is not available. Due to
-the complex deployment of a complex peace of software like a database,
-it is a common usage for the \HELM{} team to use a single and remote
-database, that may result unavailable if the user workstation lacks
-connectivity. This facility has to be intended only as a fall-back,
-since the whole \WHELP{} technology depends on the database.
-
-Decompilation guarantees that if an object is removed there are no
-dandling references to it, and that the part of the library still
-compiled is logically consistent. Since decompilation involves the
-deletion of all the outputs of the compilation, metadata included, the
-library browsable trough the \WHELP{} technology is always up to date.
-
-\subsubsection{Interactive and batch (de)compilation}
-Matita includes an interactive graphical interface and a batch
-compiler. Only the former is intended to be used directly by the
-user, the latter is automatically invoked when a not yet compiled
-part of the user development is required.
-
-While they share the same engine for compilation and decompilation,
-they provide different granularity. The batch compiler is only able to
-compile a whole script file and reciprocally it can decompile only a whole
-script, and consequently all the other scripts that rely on an object
-defined in it. The interactive interface is able to execute single steps
-of compilation, that may include the definition of an object, and
-symmetrically to undo single steps, thus removing single objects.
-
-%
-%goals: consentire sviluppo di una librearia mantenendo integrita' referenziale e usando le teconologie nostre (quindi con metadati, XML, libreria visibile)
-%\subsubsection{Composition}
-%scripts.ma, .moo, XML, metadata
-%\subsubsection{Compilation}
-%analogie con compilazione classica dso.\\
-%granularita' differenti per uso interattivo e non
-%\paragraph{Batch}
-%- granularita' .ma/buri \\
-%-- motivazioni\\
-%- come si calcolano le dipendenze\\
-%- quando la si usa\\
-%- metodi (cc e clean)\\
-%- garanzie
-%\paragraph{Interactive}
-%- granularita' fine\\
-%-- motivazioni
-%\label{sec:libmanagement}
-%consistenza: integrita' referenziale
-%Goals: mantenere consistente la rappresentazione della libreria su memoria persistente consentendo di compilare e decompilare le compilation unit (.ma).\\
-%Vincoli: dipendenze oggetti-oggetti e metadati-oggetti\\
-%Due livelli di gestione libreria, uno e' solo in fase interattiva dove la compilazione e' passo passo: \\
-%--- granularita' oggetto per matita interactive\\
-%--- granularita' baseuri (compilation unit) per la libreria\\
-%In entrmbi i casi ora:\\
-%--- matitaSync: add, remove, timetravel(facility-macro tra 2 stati)[obj]\\
-%--- matitaCleanLib: clean\_baseuri (che poi usa matitaSync a sua volta)[comp1]\\
-%Vincoli di add: typecheck ( ==$>$ tutto quello che usa sta in lib)\\
-%Vincoli di remove: \\
-%--- la remove di mSync non li controlla (ma sa cosa cancellare per ogni uri)\\
-%--- la clean\_baseuri calcola le dipendenze con i metadati (o anche i moo direi) e li rispetta\\
-%Undo di matita garantisce la consistenza a patto che l'history che tiene sia ok\\
-%Undo della lib (mClean) garantisce la consistenza (usando moo o Db).\\
-
-\subsection{Automation}
-
-\subsection{Matita's naming convention}
-A minor but not entirely negligible aspect of Matita is that of
-adopting a (semi)-rigid naming convention for identifiers, derived by
-our studies about metadata for statements.
-The convention is only applied to identifiers for theorems
-(not definitions), and relates the name of a proof to its statement.
-The basic rules are the following:
-\begin{itemize}
-\item each identifier is composed by an ordered list of (short)
-names occurring in a left to right traversal of the statement;
-\item all identifiers should (but this is not strictly compulsory)
-separated by an underscore,
-\item identifiers in two different hypothesis, or in an hypothesis
-and in the conlcusion must be separated by the string ``\verb+_to_+'';
-\item the identifier may be followed by a numerical suffix, or a
-single or duoble apostrophe.
-
-\end{itemize}
-Take for instance the theorem
-\[\forall n:nat. n = plus \; n\; O\]
-Possible legal names are: \verb+plus_n_O+, \verb+plus_O+,
-\verb+eq_n_plus_n_O+ and so on.
-Similarly, consider the theorem
-\[\forall n,m:nat. n<m \to n \leq m\]
-In this case \verb+lt_to_le+ is a legal name,
-while \verb+lt_le+ is not.\\
-But what about, say, the symmetric law of equality? Probably you would like
-to name such a theorem with something explicitly recalling symmetry.
-The correct approach,
-in this case, is the following. You should start with defining the
-symmetric property for relations
-
-\[definition\;symmetric\;= \lambda A:Type.\lambda R.\forall x,y:A.R x y \to R y x \]
-
-Then, you may state the symmetry of equality as
-\[ \forall A:Type. symmetric \;A\;(eq \; A)\]
-and \verb+symmetric_eq+ is valid Matita name for such a theorem.
-So, somehow unexpectedly, the introduction of semi-rigid naming convention
-has an important benefical effect on the global organization of the library,
-forcing the user to define abstract notions and properties before
-using them (and formalizing such use).
-
-Two cases have a special treatment. The first one concerns theorems whose
-conclusion is a (universally quantified) predicate variable, i.e.
-theorems of the shape
-$\forall P,\dots.P(t)$.
-In this case you may replace the conclusion with the word
-``elim'' or ``case''.
-For instance the name \verb+nat_elim2+ is a legal name for the double
-induction principle.
-
-The other special case is that of statements whose conclusion is a
-match expression.
-A typical example is the following
-\begin{verbatim}
- \forall n,m:nat.
- match (eqb n m) with
- [ true \Rightarrow n = m
- | false \Rightarrow n \neq m]
-\end{verbatim}
-where $eqb$ is boolean equality.
-In this cases, the name can be build starting from the matched
-expression and the suffix \verb+_to_Prop+. In the above example,
-\verb+eqb_to_Prop+ is accepted.
-
-\section{The \MATITA{} user interface}
-
-
-
\subsection{Disambiguation}
+\label{sec:disambiguation}
Software applications that involve input of mathematical content should strive
to require the user as less drift from informal mathematics as possible. We
Sect.~\ref{sec:contentintro}.
The key component of the translation is the generic disambiguation algorithm
-implemented in the \texttt{disambiguation} library of Fig.~\ref{fig:libraries}
+implemented in the \texttt{disambiguation} component of Fig.~\ref{fig:libraries}
and presented in~\cite{disambiguation}. In this section we present how to use
such an algorithm in the context of the development of a library of formalized
mathematics. We will see that using multiple passes of the algorithm, varying
expressiveness.
\subsubsection{Disambiguation aliases}
-\label{aliases}
+\label{sec:disambaliases}
Let's start with the definition of the ``strictly greater then'' notion over
(Peano) natural numbers.
The \texttt{include} statement adds the requirement that the part of the library
defining the notion of natural numbers should be defined before
-processing the following definition. Note indeed that the algorithm presented
+processing the what follows. Note indeed that the algorithm presented
in~\cite{disambiguation} does not describe where interpretations for ambiguous
expressions come from, since it is application-specific. As a first
approximation, we will assume that in \MATITA{} they come from the library (i.e.
Unfortunately, none of the passes described above is able to disambiguate its
type, no matter how aliases are defined. This is because the \OP{<} operator
occurs twice in the content level term (it has two \emph{instances}) and two
-different interpretation for it have to be used in order to obtain a refinable
+different interpretations for it have to be used in order to obtain a refinable
partially specified term. To address this issue, we have the ability to consider
each instance of a single symbol as a different ambiguous expression in the
content level term, and thus we can assign a different interpretation to each of
others). For this reason we always attempt a fresh instances pass only after
attempting a non-fresh one.
+\paragraph{One-shot aliases} Disambiguation aliases as seen so far are
+instance-independent. However, aliases obtained as a result of a disambiguation
+pass which uses fresh instances ought to be instance-dependent, that is: to
+ensure a term can be disambiguated in a batch fashion we may need to state that
+an \emph{i}-th instance of a symbol should be mapped to a given partially
+specified term. Instance-depend aliases are meaningful only for the term whose
+disambiguation generated it. For this reason we call them \emph{one-shot
+aliases} and \MATITA{} doesn't use it to disambiguate further terms down in the
+script.
+
\subsubsection{Implicit coercions}
Let's now consider a (rather hypothetical) theorem about derivation:
twice that coercion on the left hand side of the implication. The obtained
partially specified term however would not probably be the expected one, being a
theorem which prove a trivial implication. For this reason we choose to always
-prefer fresh instances over implicit coercion, i.e. we always attempt
-disambiguation passes with fresh instances before attempting passes with
-implicit coercions.
+prefer fresh instances over implicit coercions, i.e. we always attempt
+disambiguation passes with fresh instances and no implicit coercions before
+attempting passes with implicit coercions.
\subsubsection{Disambiguation passes}
-\TODO{spiegazione della tabella}
+According to the criteria described above in \MATITA{} we choose to perform the
+sequence of disambiguation passes depicted in Tab.~\ref{tab:disambpasses}. In
+our experience that choice implements a good trade off among disambiguation time
+and admitted ambiguity in terms input by users.
-\begin{center}
- \begin{tabular}{c|c|c|c}
- \multicolumn{1}{p{1.5cm}|}{\centering\raisebox{-1.5ex}{\textbf{Pass}}}
- & \multicolumn{1}{p{2.5cm}|}{\centering\textbf{Operator instances}}
- & \multicolumn{1}{p{3.1cm}|}{\centering\textbf{Disambiguation aliases}}
- & \multicolumn{1}{p{2.5cm}}{\centering\textbf{Implicit coercions}} \\
- \hline
- \PASS & Normal & Mono & Disabled \\
- \PASS & Normal & Multi & Disabled \\
- \PASS & Fresh & Mono & Disabled \\
- \PASS & Fresh & Multi & Disabled \\
- \PASS & Fresh & Mono & Enabled \\
- \PASS & Fresh & Multi & Enabled \\
- \PASS & Fresh & Library & Enabled
- \end{tabular}
-\end{center}
+\begin{table}[ht]
+ \caption{Sequence of disambiguation passes used in \MATITA.\strut}
+ \label{tab:disambpasses}
+ \begin{center}
+ \begin{tabular}{c|c|c|c}
+ \multicolumn{1}{p{1.5cm}|}{\centering\raisebox{-1.5ex}{\textbf{Pass}}}
+ & \multicolumn{1}{p{3.1cm}|}{\centering\textbf{Disambiguation aliases}}
+ & \multicolumn{1}{p{2.5cm}|}{\centering\textbf{Operator instances}}
+ & \multicolumn{1}{p{2.5cm}}{\centering\textbf{Implicit coercions}} \\
+ \hline
+ \PASS & Mono aliases & Shared & Disabled \\
+ \PASS & Multi aliases & Shared & Disabled \\
+ \PASS & Mono aliases & Fresh instances & Disabled \\
+ \PASS & Multi aliases & Fresh instances & Disabled \\
+ \PASS & Mono aliases & Fresh instances & Enabled \\
+ \PASS & Multi aliases & Fresh instances & Enabled \\
+ \PASS & Library aliases& Fresh instances & Enabled
+ \end{tabular}
+ \end{center}
+\end{table}
-\TODO{alias one shot}
+\subsection{Compilation and cleaning}
+\label{sec:libmanagement}
+%
+%goals: consentire sviluppo di una librearia mantenendo integrita' referenziale e usando le teconologie nostre (quindi con metadati, XML, libreria visibile)
+%\subsubsection{Composition}
+%scripts.ma, .moo, XML, metadata
+%\subsubsection{Compilation}
+%analogie con compilazione classica dso.\\
+%granularita' differenti per uso interattivo e non
+%\paragraph{Batch}
+%- granularita' .ma/buri \\
+%-- motivazioni\\
+%- come si calcolano le dipendenze\\
+%- quando la si usa\\
+%- metodi (cc e clean)\\
+%- garanzie
+%\paragraph{Interactive}
+%- granularita' fine\\
+%-- motivazioni
+%\label{sec:libmanagement}
+%consistenza: integrita' referenziale
+%Goals: mantenere consistente la rappresentazione della libreria su
+%memoria persistente consentendo di compilare e pulire le compilation
+%unit (.ma).\\
+%Vincoli: dipendenze oggetti-oggetti e metadati-oggetti\\
+%Due livelli di gestione libreria, uno e' solo in fase interattiva dove la compilazione e' passo passo: \\
+%--- granularita' oggetto per matita interactive\\
+%--- granularita' baseuri (compilation unit) per la libreria\\
+%In entrmbi i casi ora:\\
+%--- matitaSync: add, remove, timetravel(facility-macro tra 2 stati)[obj]\\
+%--- matitaCleanLib: clean\_baseuri (che poi usa matitaSync a sua volta)[comp1]\\
+%Vincoli di add: typecheck ( ==$>$ tutto quello che usa sta in lib)\\
+%Vincoli di remove: \\
+%--- la remove di mSync non li controlla (ma sa cosa cancellare per ogni uri)\\
+%--- la clean\_baseuri calcola le dipendenze con i metadati (o anche i moo direi) e li rispetta\\
+%Undo di matita garantisce la consistenza a patto che l'history che tiene sia ok\\
+%Undo della lib (mClean) garantisce la consistenza (usando moo o Db).\\
+The aim of this section is to describe the way \MATITA{}
+preserves the consistency and the availability of the library
+using the \WHELP{} technology, in response to the user addition or
+removal of mathematical objects.
+As already sketched in \ref{fully-spec} the output of the
+compilation of a script is split among two storage media, a
+classical filesystem and a relational database. The former is used to
+store the XML encoding of the objects defined in the script, the
+disambiguation aliases and the interpretation and notational convention defined,
+while the latter is used to store all the metadata needed by
+\WHELP{}.
+While the consistency of the data store in the two media has
+nothing to do with the nature of
+the content of the library and is thus uninteresting (but really
+tedious to implement and keep bug-free), there is a deeper
+notion of mathematical consistency we need to provide. Each object
+must reference only defined object (i.e. each proof must use only
+already proved theorems).
+
+We will focus on how \MATITA{} ensures the interesting kind
+of consistency during the formalization of a mathematical theory,
+giving the user the freedom of adding, removing, modifying objects
+without loosing the feeling of an always visible and browsable
+library.
+
+\subsubsection{Compilation}
+
+The typechecker component guarantees that if an object is well typed
+it depends only on well typed objects available in the library,
+that is exactly what we need to be sure that the logic consistency of
+the library is preserved. We have only to find the right order of
+compilation of the scripts that compose the user development.
+
+For this purpose we provide a tool called \MATITADEP{}
+that takes in input the list of files that compose the development and
+outputs their dependencies in a format suitable for the GNU \texttt{make} tool.
+The user is not asked to run \MATITADEP{} by hand, but
+simply to tell \MATITA{} the root directory of his development (where all
+script files can be found) and \MATITA{} will handle all the compilation
+related tasks, including dependencies calculation.
+To compute dependencies it is enough to look at the script files for
+inclusions of other parts of the development or for explicit
+references to other objects (i.e. with explicit aliases, see
+\ref{sec:disambaliases}).
+
+The output of the compilation is immediately available to the user
+trough the \WHELP{} technology, since all metadata are stored in a
+user-specific area of the database where the search engine has read
+access, and all the automated tactics that operates on the whole
+library, like \AUTO, have full visibility of the newly defined objects.
+
+Compilation is rather simple, and the only tricky case is when we want
+to compile again the same script, maybe after the removal of a
+theorem. Here the policy is simple: clean the output before recompiling.
+As we will see in the next section cleaning will ensure that
+there will be no theorems in the development that depends on the
+removed items.
+
+\subsubsection{Cleaning}
+
+With the term ``cleaning'' we mean the process of removing all the
+results of an object compilation. In order to keep the consistency of
+the library, cleaning an object requires the (recursive) cleaning
+of all the objects that depend on it (\emph{reverse dependencies}).
+
+The calculation of the reverse dependencies can be computed in two
+ways, using the relational database or using a simpler set of metadata
+that \MATITA{} saves in the filesystem as a result of compilation. The
+former technique is the same used by the \emph{Dependency Analyzer}
+described in \cite{zack-master} and really depends on a relational
+database.
+
+The latter is a fall-back in case the database is not
+available.\footnote{Due to the complex deployment of a large piece of
+software like a database, it is a common practice for the \HELM{} team
+to use a shared remote database, that may be unavailable if the user
+workstation lacks network connectivity.} This facility has to be
+intended only as a fall-back, since the queries of the \WHELP{}
+technology depend require a working database.
+
+Cleaning guarantees that if an object is removed there are no dandling
+references to it, and that the part of the library still compiled is
+consistent. Since cleaning involves the removal of all the results of
+the compilation, metadata included, the library browsable trough the
+\WHELP{} technology is always kept up to date.
+
+\subsubsection{Batch vs Interactive}
+
+\MATITA{} includes an interactive graphical interface and a batch
+compiler (\MATITAC). Only the former is intended to be used directly by the
+user, the latter is automatically invoked when a
+part of the user development is required (for example issuing an
+\texttt{include} command) but not yet compiled.
+
+While they share the same engine for compilation and cleaning, they
+provide different granularity. The batch compiler is only able to
+compile a whole script and similarly to clean only a whole script
+(together with all the other scripts that rely on an object defined in
+it). The interactive interface is able to execute single steps of
+compilation, that may include the definition of an object, and
+similarly to undo single steps. Note that in the latter case there is
+no risk of introducing dangling references since the \MATITA{} user
+interface inhibit undoing a step which is not the last executed.
+
+\subsection{Automation}
+
+\subsection{Naming convention}
+A minor but not entirely negligible aspect of \MATITA{} is that of
+adopting a (semi)-rigid naming convention for identifiers, derived by
+our studies about metadata for statements.
+The convention is only applied to identifiers for theorems
+(not definitions), and relates the name of a proof to its statement.
+The basic rules are the following:
+\begin{itemize}
+\item each identifier is composed by an ordered list of (short)
+names occurring in a left to right traversal of the statement;
+\item all identifiers should (but this is not strictly compulsory)
+separated by an underscore,
+\item identifiers in two different hypothesis, or in an hypothesis
+and in the conlcusion must be separated by the string ``\verb+_to_+'';
+\item the identifier may be followed by a numerical suffix, or a
+single or duoble apostrophe.
+
+\end{itemize}
+Take for instance the theorem
+\[\forall n:nat. n = plus \; n\; O\]
+Possible legal names are: \verb+plus_n_O+, \verb+plus_O+,
+\verb+eq_n_plus_n_O+ and so on.
+Similarly, consider the theorem
+\[\forall n,m:nat. n<m \to n \leq m\]
+In this case \verb+lt_to_le+ is a legal name,
+while \verb+lt_le+ is not.\\
+But what about, say, the symmetric law of equality? Probably you would like
+to name such a theorem with something explicitly recalling symmetry.
+The correct approach,
+in this case, is the following. You should start with defining the
+symmetric property for relations
+
+\[definition\;symmetric\;= \lambda A:Type.\lambda R.\forall x,y:A.R x y \to R y x \]
+
+Then, you may state the symmetry of equality as
+\[ \forall A:Type. symmetric \;A\;(eq \; A)\]
+and \verb+symmetric_eq+ is valid \MATITA{} name for such a theorem.
+So, somehow unexpectedly, the introduction of semi-rigid naming convention
+has an important benefical effect on the global organization of the library,
+forcing the user to define abstract notions and properties before
+using them (and formalizing such use).
+
+Two cases have a special treatment. The first one concerns theorems whose
+conclusion is a (universally quantified) predicate variable, i.e.
+theorems of the shape
+$\forall P,\dots.P(t)$.
+In this case you may replace the conclusion with the word
+``elim'' or ``case''.
+For instance the name \verb+nat_elim2+ is a legal name for the double
+induction principle.
+
+The other special case is that of statements whose conclusion is a
+match expression.
+A typical example is the following
+\begin{verbatim}
+ \forall n,m:nat.
+ match (eqb n m) with
+ [ true \Rightarrow n = m
+ | false \Rightarrow n \neq m]
+\end{verbatim}
+where $eqb$ is boolean equality.
+In this cases, the name can be build starting from the matched
+expression and the suffix \verb+_to_Prop+. In the above example,
+\verb+eqb_to_Prop+ is accepted.
+
+\section{The authoring interface}
+
+\begin{figure}[t]
+ \begin{center}
+ \includegraphics[width=0.95\textwidth]{matita-screenshot}
+ \caption{\MATITA{} look and feel}
+ \label{fig:screenshot}
+ \end{center}
+\end{figure}
+
+\MATITA{} has a script based user interface. As can be seen in Fig.~... it is
+split in two main windows: on the left a textual widget is used to edit the
+script, on the right the list of open goal is shown using a \MATHML{} rendering
+widget. A distinguished part of the script (shaded in the screenshot) represent
+the commands already executed and can't be edited without undoing them. The
+remaining part can be freely edited and commands from that part can be executed
+moving down the execution point. An additional window --- the ``cicBrowser'' ---
+can be used to browse the library, including the proof being developed, and
+enable content based search on it. In the cicBrowser proofs are rendered in
+natural language, automatically generated from the low-level $\lambda$-terms
+using techniques inspired by \cite{natural,YANNTHESIS}.
+
+%In the \MATITA{} philosophy the script is not relevant \emph{per se}, but is
+%only seen as a convenient way to create mathematical objects. The universe of
+%all these objects makes up the \HELM{} library, which is always completely
+%visible to the user. The mathematical library is thus conceived as a global
+%hypertext, where objects may freely reference each other. It is a duty of
+%the system to guide the user through the relevant parts of the library.
+
+%This methodological assumption has many important consequences
+%which will be discussed in the next section.
+
+%on one side
+%it requires functionalities for the overall management of the library,
+%%%%%comprising efficient indexing techniques to retrieve and filter the
+%information;
+%on the other it introduces overloading in the use of
+%identifiers and mathematical notation, requiring sophisticated disambiguation
+%techniques for interpreting the user inputs.
+%In the next two sections we shall separately discuss the two previous
+%points.
+
+%In order to maximize accessibility mathematical objects are encoded in XML. (As%discussed in the introduction,) the modular architecture of \MATITA{} is
+%organized in components which work on data in this format. For instance the
+%rendering engine, which transform $\lambda$-terms encoded as XML document to
+%\MATHML{} Presentation documents, can be used apart from \MATITA{} to print ...
+%FINIRE
+
+A final section is devoted to some innovative aspects
+of the authoring system, such as a step by step tactical execution,
+content selection and copy-paste.
\subsection{Patterns}
-serve una intro che almeno cita il widget (per i patterns) e che fa
-il resoconto delle cose che abbiamo e che non descriviamo,
-sottolineando che abbiamo qualcosa da dire sui pattern e sui
-tattichini.\\
+\subsubsection{Direct manipulation of terms}
-Patterns are the textual counterpart of the MathML widget graphical
-selection.
+While terms are input as \TeX-like formulae in \MATITA, they're converted to a
+mixed \MATHML+\BOXML{} markup for output purposes and then rendered by
+\GTKMATHVIEW. This mixed choice~\cite{latexmathml} enables both high-quality
+bidimensional rendering of terms (including the use of fancy layout schemata
+like radicals and matrices~\cite{mathml}) and the use of a concise and
+widespread textual syntax.
-Matita benefits of a graphical interface and a powerful MathML rendering
-widget that allows the user to select pieces of the sequent he is working
-on. While this is an extremely intuitive way for the user to
-restrict the application of tactics, for example, to some subterms of the
-conclusion or some hypothesis, the way this action is recorded to the text
-script is not obvious.\\
-In \MATITA{} this issue is addressed by patterns.
+\begin{figure}[t]
+ \begin{center}
+ \includegraphics[width=0.40\textwidth]{matita-screenshot-selection}
+ \hspace{0.05\textwidth}
+ \raisebox{0.4cm}{\includegraphics[width=0.50\textwidth]{matita-screenshot-href}}
+ \caption{Semantic selection and hyperlinks}
+ \label{fig:directmanip}
+ \end{center}
+\end{figure}
+
+Keeping pointers from the presentations level terms down to the
+partially specified ones \MATITA{} enable direct manipulation of
+rendered (sub)terms in the form of hyperlinks and semantic selection.
+\emph{Hyperlinks} have anchors on the occurrences of constant and
+inductive type constructors and point to the corresponding definitions
+in the library. Anchors are available notwithstanding the use of
+user-defined mathematical notation: as can be seen on the right of
+Fig.~\ref{fig:directmanip}, where we clicked on $\not|$, symbols
+encoding complex notations retain all the hyperlinks of constants or
+constructors used in the notation.
+
+\emph{Semantic selection} enable the selection of mixed
+\MATHML+\BOXML{} markup, constraining the selection to markup
+representing meaningful CIC (sub)terms. In the example on the left of
+Fig.~\ref{fig:directmanip} is thus possible to select the subterm
+$\mathrm{prime}~n$, whereas it would not be possible to select
+$\forall~n:nat$ since the former denotes an application while the
+latter denotes an incomplete $\Pi$-binder. Once a (sub)term has been
+selected that way actions can be done on it like reductions or tactic
+applications.
+
+In our experience working with direct manipulation of terms is really
+effective and faster than retyping them. Nonetheless we need a way to
+encode term selections in scripts so that they can be batch compiled
+by \MATITAC. In \MATITA{} \emph{patterns} implement that encoding,
+being patterns the textual representations of \GTKMATHVIEW{} semantic
+selections. \NOTE{Zack:c'\`e scritto da qualche parte che l'utente
+non li deve necessariamente scrivere a mano, ma che pu\`o incollarli?
+Va scritto.}
\subsubsection{Pattern syntax}
A pattern is composed of two terms: a $\NT{sequent\_path}$ and a
The concrete syntax is reported in table \ref{tab:pathsyn}
\NOTE{uso nomi diversi dalla grammatica ma che hanno + senso}
\begin{table}
- \caption{\label{tab:pathsyn} Concrete syntax of \MATITA{} patterns.\strut}
+ \caption{\label{tab:pathsyn} Patterns concrete syntax.\strut}
\hrule
+% \[
+% \begin{array}{@{}rcll@{}}
+% \NT{pattern} &
+% ::= & [~\verb+in match+~\NT{wanted}~]~[~\verb+in+~\NT{sequent\_path}~] & \\
+% \NT{sequent\_path} &
+% ::= & \{~\NT{ident}~[~\verb+:+~\NT{multipath}~]~\}~
+% [~\verb+\vdash+~\NT{multipath}~] & \\
+% \NT{wanted} & ::= & \NT{term} & \\
+% \NT{multipath} & ::= & \NT{term\_with\_placeholders} & \\
+% \end{array}
+% \]
\[
\begin{array}{@{}rcll@{}}
\NT{pattern} &
- ::= & [~\verb+in match+~\NT{wanted}~]~[~\verb+in+~\NT{sequent\_path}~] & \\
+ ::= & [~\verb+in+~\NT{sequent\_path}~]~[~\verb+match+~\NT{wanted}~] & \\
\NT{sequent\_path} &
::= & \{~\NT{ident}~[~\verb+:+~\NT{multipath}~]~\}~
[~\verb+\vdash+~\NT{multipath}~] & \\
- \NT{wanted} & ::= & \NT{term} & \\
\NT{multipath} & ::= & \NT{term\_with\_placeholders} & \\
+ \NT{wanted} & ::= & \NT{term} & \\
\end{array}
\]
\hrule
\end{table}
-\subsubsection{How patterns work}
+\subsubsection{Pattern concepts}
Patterns mimic the user's selection in two steps. The first one
selects roots (subterms) of the sequent, using the
$\NT{sequent\_path}$, while the second
their context that will be eventually used in the second phase.
\item[Phase 2]
- plays a role only if the $[~\verb+in match+~\NT{wanted}~]$
+ plays a role only if the $[~\verb+match+~\NT{wanted}~]$
part is specified. From the first phase we have some terms, that we
will see as subterm roots, and their context. For each of these
contexts the $\NT{wanted}$ term is disambiguated in it and the
works too and can be done, by the experienced user, writing directly
a simpler pattern that uses the second phase.
\begin{grafite}
- change in match n in H with (O + n).
+ change in H match n with (O + n).
\end{grafite}
\noindent
In this case the $\NT{sequent\_path}$ selects the whole $H$, while
in un pattern phase1only come faccio nell'ultimo esempio. lo si fa
con una pattern\_of(select(pattern))}
-\subsubsection{Comparison with Coq}
-Coq has a two diffrent ways of restricting the application of tactis to
+\subsubsection{Comparison with \COQ{}}
+\COQ{} has a two diffrent ways of restricting the application of tactis to
subterms of the sequent, both relaying on the same special syntax to identify
a term occurrence.
\MATITA{} tacticals syntax is reported in table \ref{tab:tacsyn}.
While one would expect to find structured constructs like
$\verb+do+~n~\NT{tactic}$ the syntax allows pieces of tacticals to be written.
-This is essential for base idea behind matita tacticals: step-by-step execution.
+This is essential for base idea behind \MATITA{} tacticals: step-by-step
+execution.
The low-level tacticals implementation of \MATITA{} allows a step-by-step
execution of a tactical, that substantially means that a $\NT{block\_kind}$ is
\item[Proof structuring]
is much easier. Consider for example a proof by induction, and imagine you
are using classical tacticals in one of the state of the
- art graphical interfaces for proof assistant like Proof General or Coq Ide.
+ art graphical interfaces for proof assistant like Proof General or \COQIDE.
After applying the induction principle you have to choose: structure
the proof or not. If you decide for the former you have to branch with
``\texttt{[}'' and write tactics for all the cases separated by
goal) gives you the feeling of what is going on.
\end{description}
-\section{The Matita library}
+\section{Standard library}
-Matita is Coq compatible, in the sense that every theorem of Coq
+\MATITA{} is \COQ{} compatible, in the sense that every theorem of \COQ{}
can be read, checked and referenced in further developments.
However, in order to test the actual usability of the system, a
new library of results has been started from scratch. In this case,
of course, we wrote (and offer) the source script files,
-while, in the case of Coq, Matita may only rely on XML files of
-Coq objects.
+while, in the case of \COQ, \MATITA{} may only rely on XML files of
+\COQ{} objects.
The current library just comprises about one thousand theorems in
elementary aspects of arithmetics up to the multiplicative property for
Eulers' totient function $\phi$.
factorization.ma & chinese\_reminder.ma & fermat\_little\_th.ma \\
totient.ma& & \\
\end{array}$
-\caption{\label{scripts}Matita scripts on natural numbers}
+\caption{\label{scripts}\MATITA{} scripts on natural numbers}
\end{figure}
We do not plan to maintain the library in a centralized way,
\acknowledgements
We would like to thank all the students that during the past
five years collaborated in the \HELM{} project and contributed to
-the development of Matita, and in particular
+the development of \MATITA{}, and in particular
M.~Galat\`a, A.~Griggio, F.~Guidi, P.~Di~Lena, L.~Padovani, I.~Schena, M.~Selmi,
and V.~Tamburrelli.
projects / helm.git / blobdiff