+\subsubsection{Batch vs Interactive}
+
+\MATITA{} includes an interactive authoring interface and a batch
+``compiler'' (\MATITAC).
+
+Only the former is intended to be used directly by the
+user, the latter is automatically invoked by \MATITA{}
+to regenerate parts of the library previously invalidated.
+
+While they share the same engine for generation and invalidation, they
+provide different granularity. \MATITAC{} is only able to re-execute a
+whole script and similarly to invalidate all the concepts generated
+by a script (together with all the other scripts that rely on a concept defined
+in it).
+
+\subsection{Automation}
+\label{sec:automation}
+
+In the long run, one would expect to work with a proof assistant
+like \MATITA, using only three basic tactics: \TAC{intro}, \TAC{elim},
+and \TAC{auto}
+(possibly integrated by a moderate use of \TAC{cut}). The state of the art
+in automated deduction is still far away from this goal, but
+this is one of the main development direction of \MATITA.
+
+Even in this field, the underlying philosophy of \MATITA{} is to
+free the user from any burden relative to the overall management
+of the library. For instance, in \COQ, the user is responsible to
+define small collections of theorems to be used as a parameter
+by the \TAC{auto} tactic;
+in \MATITA, it is the system itself that automatically retrieves, from
+the whole library, a subset of theorems worth to be considered
+according to the signature of the current goal and context.
+
+The basic tactic merely iterates the use of the \TAC{apply} tactic
+(with no \TAC{intro}). The search tree may be pruned according to two
+main parameters: the \emph{depth} (whit the obvious meaning), and the
+\emph{width} that is the maximum number of (new) open goals allowed at
+any instant. \MATITA{} has only one notion of metavariable, corresponding
+to the so called existential variables of \COQ; so, \MATITA's \TAC{auto}
+tactic should be compared with \COQ's \TAC{EAuto} tactic.
+
+Recently we have extended automation with paramodulation based
+techniques. At present, the system works reasonably well with
+equational rewriting, where the notion of equality is parametric
+and can be specified by the user: the system only requires
+a proof of {\em reflexivity} and {\em paramodulation} (or rewriting,
+as it is usually called in the proof assistant community).
+
+Given an equational goal, \MATITA{} recovers all known equational facts
+from the library (and the local context), applying a variant of
+the so called {\em given-clause algorithm}~\cite{paramodulation},
+that is the the procedure currently used by the majority of modern
+automatic theorem provers.
+
+The given-clause algorithm is essentially composed by an alternation
+of a \emph{saturation} phase and a \emph{demodulation} phase.
+The former derives new facts by a set of active
+facts and a new \emph{given} clause suitably selected from a set of passive
+equations. The latter tries to simplify the equations
+orienting them according to a suitable weight associated to terms.
+\MATITA{} currently supports several different weighting functions
+comprising Knuth-Bendix ordering (kbo) and recursive path ordering (rpo),
+that integrates particularly well with normalization.
+
+Demodulation alone is already a quite powerful technique, and
+it has been turned into a tactic by itself: the \TAC{demodulate}
+tactic, which can be seen as a kind of generalization of \TAC{simplify}.
+The following portion of script describes two
+interesting cases of application of this tactic (both of them relying
+on elementary arithmetic equations):
+
+\begin{grafite}
+theorem example1:
+ \forall x: nat. (x+1)*(x-1) = x*x - 1.
+intro.
+apply (nat_case x);
+ [ simplify; reflexivity
+ | intro; demodulate; reflexivity ]
+qed.
+\end{grafite}
+
+\begin{grafite}
+theorem example2:
+ \forall x,y: nat. (x+y)*(x+y) = x*x + 2*x*y + y*y.
+intros; demodulate; reflexivity
+qed.
+\end{grafite}
+
+In the future we expect to integrate applicative and equational
+rewriting. In particular, the overall idea would be to integrate
+applicative rewriting with demodulation, treating saturation as an
+operation to be performed in batch mode, e.g. during the night.
+
+\subsection{Naming convention}
+\label{sec:naming}
+
+A minor but not entirely negligible aspect of \MATITA{} is that of
+adopting a (semi)-rigid naming convention for concept names, derived by
+our studies about metadata for statements.
+The convention is only applied to theorems
+(not definitions), and relates theorem names to their statements.
+The basic rules are the following:
+\begin{itemize}
+
+ \item each name is composed by an ordered list of (short)
+ identifiers occurring in a left to right traversal of the statement;
+
+ \item all names should (but this is not strictly compulsory)
+ separated by an underscore;
+
+ \item names occurring in two different hypotheses, or in an hypothesis
+ and in the conclusion must be separated by the string \texttt{\_to\_};
+
+ \item the identifier may be followed by a numerical suffix, or a
+ single or double apostrophe.
+
+\end{itemize}
+
+Take for instance the statement:
+\begin{grafite}
+\forall n: nat. n = plus n O
+\end{grafite}
+Possible legal names are: \texttt{plus\_n\_O}, \texttt{plus\_O},
+\texttt{eq\_n\_plus\_n\_O} and so on.
+
+Similarly, consider the statement
+\begin{grafite}
+\forall n,m: nat. n < m to n \leq m
+\end{grafite}
+In this case \texttt{lt\_to\_le} is a legal name,
+while \texttt{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:
+\begin{grafite}
+definition symmetric \def
+ \lambda A: Type. \lambda R. \forall x,y: A.
+ R x y \to R y x.
+\end{grafite}
+Then, you may state the symmetry of equality as:
+\begin{grafite}
+\forall A: Type. symmetric A (eq A)
+\end{grafite}
+and \texttt{symmetric\_eq} is a legal name for such a theorem.
+
+So, somehow unexpectedly, the introduction of semi-rigid naming convention
+has an important beneficial effect on the global organization of the library,
+forcing the user to define abstract concepts 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 string
+\texttt{elim} or \texttt{case}.
+For instance the name \texttt{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{grafite}
+\forall n,m: nat.
+ match (eqb n m) with
+ [ true \Rightarrow n = m
+ | false \Rightarrow n \neq m ]
+\end{grafite}
+where \texttt{eqb} is boolean equality.
+In this cases, the name can be build starting from the matched
+expression and the suffix \texttt{\_to\_Prop}. In the above example,
+\texttt{eqb\_to\_Prop} is accepted.
+
+\section{The authoring interface}
+\label{sec:authoring}
+
+The authoring interface of \MATITA{} is very similar to Proof
+General~\cite{proofgeneral}. We
+chose not to build the \MATITA{} UI over Proof General for two reasons. First
+of all we wanted to integrate in the UI our rendering technologies, mainly
+\GTKMATHVIEW, to render sequents exploiting the bidimensional mathematical layouts
+of \MATHML-Presentation.
+At the time of writing Proof General supports only text based
+rendering.\footnote{This may change with future releases of Proof General
+based on Eclipse (\url{http://www.eclipse.org/}).} The second reason is that we wanted
+to build the \MATITA{} UI on top of a state-of-the-art and widespread graphical
+toolkit as \GTK{} is.
+
+Fig.~\ref{fig:screenshot} is a screenshot of the \MATITA{} authoring interface.
+The foreground
+window is an instance of the cicBrowser (see Sect.~\ref{sec:library}) used to
+render in natural language the proof under development.
+
+Note that the syntax used in the script view is \TeX-like, but
+Unicode\footnote{\url{http://www.unicode.org/}} is
+also fully supported so that mathematical glyphs can be input as such.
+
+\begin{figure}[!ht]
+ \begin{center}
+ \includegraphics[width=0.95\textwidth]{pics/matita-screenshot}
+ \caption{Authoring interface\strut}
+ \label{fig:screenshot}
+ \end{center}
+\end{figure}
+
+Since the concepts of script based proof authoring are well-known, the
+remaining part of this section is devoted to the distinguishing
+features of the \MATITA{} authoring interface.
+
+\subsection{Direct manipulation of terms}
+\label{sec:directmanip}
+
+While terms are input as \TeX-like formulae in \MATITA, they are converted to a
+mixed \MATHML+\BOXML{} markup for output purposes and then rendered by
+\GTKMATHVIEW. As described in~\cite{latexmathml} this mixed choice enables both
+high-quality bidimensional rendering of terms (including the use of fancy
+layout schemata like radicals and matrices) and the use of a
+concise and widespread textual syntax.
+
+Keeping pointers from the presentations level terms down to the
+partially specified ones, \MATITA{} enables 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 $\nmid$, symbols
+encoding complex notations retain all the hyperlinks of constants or
+constructors used in the notation.
+
+\emph{Semantic selection} enables 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
+$\to n$ since the former denotes an application while the
+latter is not a subterm. Once a meaningful (sub)term has been
+selected actions like reductions or tactic applications can be performed on it.
+
+\begin{figure}[!ht]
+ \begin{center}
+ \includegraphics[width=0.40\textwidth]{pics/matita-screenshot-selection}
+ \hspace{0.05\textwidth}
+ \raisebox{0.4cm}{\includegraphics[width=0.50\textwidth]{pics/matita-screenshot-href}}
+ \caption[Semantic selection and hyperlinks]{Semantic selection (on the left)
+ and hyperlinks (on the right)\strut}
+ \label{fig:directmanip}
+ \end{center}
+\end{figure}
+
+\subsection{Patterns}
+\label{sec:patterns}
+
+In several situations working with direct manipulation of terms is
+simpler and faster than typing the corresponding textual
+commands~\cite{proof-by-pointing}.
+Nonetheless we need to record actions and selections in scripts.
+
+In \MATITA{} \emph{patterns} are textual representations of selections.
+Users can select using the GUI and then ask the system to paste the
+corresponding pattern in this script. More often this process is
+transparent to the user: once an action is performed on a selection,
+the corresponding
+textual command is computed and inserted in the script.