Subversion Repositories TPPL


Rev 33 | Go to most recent revision | Blame | Compare with Previous | Last modification | View Log | RSS feed

% aims
% * raw material for proposal
%   * properties of Isabelle relevant for project context
%   * comparison to other TP systems – why Isabelle?
% * communication of Isabelle to non-TP-people


We give an overview of the interactive proof assistant Isabelle/HOL \cite{Nipkow-Paulson-Wenzel:2002}
with a particular focus on properties which are relevant in our envisaged project context.

When reading this, bear in mind that the aim of this project is to
provide a running prototype environment.  This requires to focus on
one particular TP system.  This does not imply that the issues we want
to investigate could not be transferred to other TP systems as well – but
without any experience gained from a prototype, it is too early to
generalise, although this could be a focus of a future successor project.

A baseline is that only \emph{interactive} proof assistants come into question.
This rules out the vast collection of automatic provers, but also bare
programming languages like Agda \cite{adga-phd-07}.  Typical representatives of
interactive proof assistants are the Coq system,
\cite{coq-team-10}, ACL2 \cite{moore:acl2-00}, Mizar\footnote{}, the HOL
family\footnote{This covers both HOL4 \cite{Gordon:93} and HOL Light \cite{harrison:hol-light}}, and Isabelle/HOL.

A realistic crosscut through relevant properties of existing TP
systems led us to the conclusion that Isabelle/HOL (from now, just Isabelle)
is the most promising one to start with.

\section{How Isabelle/HOL presents itself}


The logical calculus of Isabelle is higher-order logic (HOL) of simply-typed
schematically polymorphic $\lambda$-terms:


  \item[types $\tau$] consist of \emph{type constructors}
    $\kappa$ with a fixed arity and type variables $\alpha$:

      \tau ::= \kappa \ \tau_1 \cdots \tau_k \ \| \ \alpha

    Function space $\alpha \Rightarrow \beta$ is simply a binary type

  \item[terms $t$] include application, abstraction,
    (local) variables of a particular type, and constants (operations):

      t ::= t_1 \ t_2 \ \| \ \lambda x :: \tau. \ t \ \| \ x :: \tau \ \| \ f

  \item[formulae $P$] are terms of a distinguished type \emph{bool}
    with the usual connectives: conjunction, disjunction, implication,
    negation, universal and existential quantifiers.  By convention,
    chained implications at the outermost level are printed as inference rules:
    $Q_1 \Longrightarrow\Longrightarrow Q_n \Longrightarrow P$ is printed
      \infer{P}{Q_1 … Q_n}

    A constant (operation) with a particular relevance for formulae
    is equality $t_1 = t_2$ of type $\alpha \Rightarrow \alpha \Rightarrow$


On top of this core calculus, Isabelle provides various predefined
type constructors with corresponding operations that resemble concepts
well-known from mathematics and functional programming:


  \item[numeric types \emph{nat}, \emph{int}, \emph{rat}, \emph{real}, \emph{complex}]
    modelling the natural, integer, rational, real and complex numbers
    with the usual arithmetic operations;

  \item[type of sets \emph{$\alpha$ set}] modelling sets as comprehensions
    over predicates of type \emph{$\alpha \Rightarrow$ bool} with typical
    operations like union, intersection, difference, set product, image
    of a set under a operation etc.

  \item[fundamental collection types \emph{unit}, $\alpha * \beta$, \emph{$\alpha$ option}, \emph{$\alpha$ list}]
    representing the common unit, product, option and list types from functional programming
    with dozens of operations similar to what can be found in typical functional
    programming libraries: membership test, concatenation, reversal, sorting, etc.

  \item[advanced data structures, e.g. red-black trees \emph{$(\alpha, \beta)$ rbt}]
    with the typical lookup, insert and delete operations
    providing efficient data structures for functional programs embedded
    in Isabelle (see \secref{code-generation}).


Isabelle also comes with syntactic sugar for \emph{if}-, \emph{let}- and
\emph{case}-expressions known from functional programming, which are
internally mapped to suitable combinators.

\subsection{Specification and proof language Isar}

To conduct formal developments, Isabelle uses the specification
and proof language \emph{Isar}.  An Isar text is
structured as a series of Isar commands, each consisting of a
particular keyword followed by text denoting logical and non-logical
entities (types, terms, names, \ldots).  Isar commands are aggregated
in theories, where one theory's content is given by the Isar commands
it contains:  commands add type constructors, constants, proofs etc.
to the theory.

Typical representatives of Isar commands are specification tools as follows:


  \item[Inductive datatypes] correspond to datatype declarations
    in functional programming languages:

    \ color\ {\isacharequal}\ R\ {\isacharbar}\ B\isanewline
    \ {\isacharparenleft}$\alpha${\isacharcomma}\ $\beta${\isacharparenright}\ rbt\ {\isacharequal}\ Empty\ {\isacharbar}\ Branch\ color\ ({\isachardoublequoteopen}{\isacharparenleft}$\alpha${\isacharcomma}\ $\beta${\isacharparenright}\ rbt{\isachardoublequoteclose})\ $\alpha$\ $\beta$\ ({\isachardoublequoteopen}{\isacharparenleft}$\alpha${\isacharcomma}\ $\beta${\isacharparenright}\ rbt{\isachardoublequoteclose})\isanewline

  \item[Recursive functions with pattern matching] correspond to function
    definitions in functional programming languages:

    \ splice\ {\isacharcolon}{\isacharcolon}\ {\isachardoublequoteopen}$\alpha$\ list\ {\isasymRightarrow}\ $\alpha$\ list\ {\isasymRightarrow}\ $\alpha$\ list{\isachardoublequoteclose}\ \isakeyword{where}\isanewline
    \ {\isachardoublequoteopen}splice\ {\isacharbrackleft}{\isacharbrackright}\ ys\ {\isacharequal}\ ys{\isachardoublequoteclose}\ {\isacharbar}\isanewline
    \ {\isachardoublequoteopen}splice\ xs\ {\isacharbrackleft}{\isacharbrackright}\ {\isacharequal}\ xs{\isachardoublequoteclose}\ {\isacharbar}\isanewline
    \ {\isachardoublequoteopen}splice\ {\isacharparenleft}x\ {\isacharhash}\ xs{\isacharparenright}\ {\isacharparenleft}y\ {\isacharhash}\ ys{\isacharparenright}\ {\isacharequal}\ x\ {\isacharhash}\ y\ {\isacharhash}\ splice\ xs\ ys{\isachardoublequoteclose

    TP experts may note that recursive function definitions within
    a formal calculus require a complex machinery to construct termination
    proofs and similar.  The good news is that end-users need only seldom
    to care about that: Isabelle's function package does the job
    for a huge class of practically occurring functions


Note that Isabelle's calculus as presented here resembles an ML-like
programming language enriched with logical concepts like sets and quantifiers:
datatype and function definitions enable a user to extend the calculus with new notions
in the manner of a functional programming language, and state properties
about those newly introduced concepts.  In other words, Isabelle's can be
seen as a carrier for a shallowly embedded functional programming language;
this observation, condensed into the slogan »HOL = functional programming +
logic«, has a couple of consequences:


  \item People with a (functional) programming language background get acquainted
    with Isabelle comparably fast, and most existing introductions to Isabelle
    follow that track \cite{nipkow-prog-prove}.

  \item Algorithmic issues can be expressed directly in a functional style
    in Isabelle, which eases transfer of algorithms from CA to Isabelle.

  \item Formulations in the embedded functional programming language
    can be translated to code for common functional programming language
    systems using code generation \refme.


\fixme[elaborate: comparison to other systems]

Proofs themselves, the Holy Grail of TP systems, are conducted in a fragment
of the Isar language, the Isar \emph{proof
} language.  This is not a tutorial
%                                                      //////////////////////
on how to write Isar proofs, and in our project the envisaged end users, mainly
engineers, are not expected to come in touch with fundamental proofs at all,
%          !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
% Proofs of within domain-specific knowledge might become the duty of so-called
% domain-engineers: they do not only provide algorithms solving particular
% domain-specific problems, rather, they start with formalizing the essential
% notions of the domain by definitions, theorem and proofs
% \cite{db:SW-engIII,db:dom-eng,Hansen94b,Dehbonei&94}.
as this is rather the task of the system implementers;  therefore we will
not dive deeper here.  Nevertheless, the ability to write human-readable and
robust proofs in Isar is a key aspect to maintain voluminous formal
developments in the mid-term and long-term run.  \footnote{An ever-growing collection
of Isabelle developments is collected in the Archive of Formal Proofs\footnote{\url{}};
adjustments because of broken
proofs due to changes in the system have become seldom over the years.

%% ^^^ relates to pt.3 in TPPL-abstract.tex in particular:
%% with this go into detail in \sect{Methods}

\fixme[elaborate: comparison to other systems]

\subsection{A bluffer's glance at Isabelle's architecture}\label{architecture}

This short overview provides the context to understand the subsequent technical



\item Interaction with the system nowadays happens through
  an IDE (see \secref{jedit}) which is implemented
  in Scala \footnote{\url{}; Scala combines an industry-proven
  runtime environment, the Java Virtual Machine (JVM), with a state-of-the-art
  type-safe general purpose programming language.}.

\item The interactive prover itself acts as a backend to the IDE
  and is implemented in Standard ML.  The languages of the ML family are standard workhorses
  for interactive provers; Isabelle prefers PolyML which excels especially
  in parallelism (see \secref{parallel}).

\item External non-interactive provers can be hooked to the core prover
  (see \secref{external}).

\item Code generation allows to turn suitable specifications
  into programs (see \secref{code-generation}).


\subsection{The jEdit user interface}\label{jedit}

Traditionally, TP systems have a reputation of being difficult to access.
Recent developments in Isabelle attempt to overcome this by providing
a state-of-the-art editor framework (jEdit) with a plugin establishing
an IDE-like feeling when editing Isabelle theories:


The key idea to make this work is continuous proof checking:  the theory
source text is annotated by semantic information by the proof assistant as it becomes
available incrementally.  This works via an asynchronous
protocol that neither blocks the editor nor stops the proof assistant from
exploiting parallelism on multi-core hardware

User interface support is vital to our project aims.  The traditional
users of TP systems have mostly been scientists engaging in logic or
verification with a strong background in computer science, who would
find their individual ways to cope with the arcane TP system interfaces.
If we want to target engineers, we cannot expect them to develop
a similar hackitude, but must strive to provide a system with a user
interface similar to what one can expect today from computer tools.

Since Isabelle's jEdit interface is JVM-based, existing visualisation
tools in Java, e.g. for drawing function graphs, could be incorporated
if this turns out to be necessary.

The continuous proof checking approach with all its consequences
currently is unique to Isabelle, setting it apart in this respect.

\section{System architecture}

\subsection{Reconciling trustability and extensibility – the LCF approach}

Isabelle is a proof assistant in the LCF tradition: each proof or theorem
is internally represented by a value of an abstract type \verb!thm! in
the underlying (type-safe!) implementation language which can only be
manipulated by a few trusted primitive operations, the so-called
inference kernel \cite{meta-ML-79}.  Therefore any construction of proofs
in the run-time system boils down to operations from the inference kernel.
This results in high trustability.  What makes this rigorous approach scale
is that there is no fundamental distinction between operations or theorems
which are built-in in the sense of the inference kernel, and derived ones.  This
allows to derive operations and corresponding proof rules in terms of existing ones
but to ignore their construction later on.  E.g. existential quantification
$\exists$\footnote{Existential quantification itself is indeed no built-in but a derived concept}
comes with two natural-deduction-style \citeme inference rules

  \infer[{ex}_{intro}]{\exists x. P \: x}{P \: t} \quad
  \infer[{ex}_{elim}]{R}{\exists x. P \: x && (\forall x. P \: x \Longrightarrow R)}

Defining divisibility on the natural numbers using multiplication on natural numbers

  m \| n = (\exists q. n = q * m)

the following natural-deduction-style inference rules for divisibility can be derived

  \infer[{divides}_{intro}]{m \| n}{n = q * m} \quad
  \infer[{divides}_{elim}]{R}{m \| n && (\forall q. n = q * m \Longrightarrow R)}

Reasoning on divisibility then may continue using these two rules, regardless
how the original definition of divisibility and the proofs of the corresponding
inference rules have been accomplished.

\fixme[evaluate and compare to other systems]

\subsection{Programmatic extensibility}

Since theorems are values in the underlying ML implementation language, they
can be manipulated by arbitrary programmatic means.  This allows to automate
complex specification and proof steps.
Prominent examples are the function package
mentioned above \refme, or Isabelle's simplifier which enables the user
to perform equational reasoning automatically.

An instance in our project context could be to provide trusted
computation machineries, e.g.~accompany Isabelle's Kurzweil-Henstock
Gauge Integration \cite{kurzweil-henstock:integral-00} in many dimensions with tools to actually
compute integrals.

\fixme[compare to other systems]

\subsection{Syntax variability}

Isabelle's syntax in large parts is not hard-wired to the system.  This
allows to customise the appearance of commands, terms etc. with high degrees
of freedom.  In the context of computer science, this is not really an issue:
computer scientists are used to switch between different notational conventions
as needed.  However, we want to approach engineers with a different attitude
and approximate notation found in engineering literature as close as possible and appropriate.

\fixme[example: example from engineering book, example in Isabelle »as it is«, possible variant of Isabelle syntax]

\fixme[compare to other systems]

\section{Speedful computation}

Proof assistants are designed for proofs, but often do not perform
very well on computations \footnote{This goes back to the first edition
of Russell's \emph{Principia}, where the proof of $1 + 1 = 2$ appears
only on page 379.}
The deeper reason is that by their very nature proof assistants carry out
computations \emph{symbolically} which is quite heavyweight.
In this section we discuss some devices to make computations in Isabelle
feasible in practice.

\subsection{Parallel computation}\label{parallel}

Recent releases of Isabelle exploit parallelism on multicore machines
\cite{makarius:isa-scala-jedit}.  Beside the speedup itself, this is also a device to keep
up reactivity of the system while background threads are engaged
in massive computations \secref{jedit}.  On suitable hardware, speedups
by factor of 4 to 5 have been achieved \cite{parallel-ML}.  Recent versions of
PolyML (Isabelle's run-time system) featuring parallel garbage
collection have shown further boost.

Both the parallelism facilities of the underlying run-time system as
well as the consideration and exploitation of parallelism in the
overall system architecture in combination currently set Isabelle
apart from similar systems in that respect.

\subsection{Code generation and datatype refinement}\label{code-generation

%%% code generation, datatype refinement and reflection, embedded
%programming language %% making things executable
% \cite{haftm-nipkow-code-gen-HRS-10}

% The executable fragment of Isabelle together with the function
% package and with the code generator provide a promising basis for
% prototyping such a language, more supportive and more reliable than
% a CA-based one.

% \item\label{item-comp-func}\textit{adapts the functional programming
% fragment of Isabelle}~\footnote{Some details discussed here
% specifically apply to the ``High-Order Logic (HOL)'' development
% of Isabelle.} such that it becomes appropriate for large software
% developments in engineering sciences while exploiting the power of
% Isabelle's function package and code generator.

% \subparagraph{\sc\large Extend the interpreter of
% Isabelle's code generator:} Isabelle's code generator
% \cite{nipkow-bergh-code-gen-02,haftm-nipkow-code-gen-HRS-10}
% not only generates code in several languages, but also supports
% immediate interpretation of the functions, by use of Isabelle's
% simplifier \cite{isa-codegen} and further mechanisms.

% Like Isabelle's function package, the code generator only works
% for single functions --- so major extensions are required, delving
% deeply into Isabelle's concepts and sources, most of which are
% only documented by the source code itself. A pleasant exception
% is \cite{isar-impl}, which gives some descriptions, for instance
% of contexts.

% \cite{haftm-nipkow-code-gen-HRS-10} note that ``the code generator
% supports stepwise refinement of both algorithms and data by means
% of code lemmas that replace less efficient functions and data by
% more efficient ones in a uniform and logically sound way'' ---
% such stepwise refinement shall remain in focus when tackling design
% issues of interactive program development.

\subsection{Integration of external tools}\label{external}

Over the years, various external tools have been hooked to the Isabelle
system, e.g. first-order provers for the sledgehammer proof searcher \cite{sledgehammer-10},
SAT solvers for the nitpick counterexample searcher \cite{nitpick-10}, etc.

These external tools are generally useful on their own;  even
more relevant is the shared generic infrastructure to connect Isabelle
to external tools, which turns Isabelle into a system hub for gluing together
various kinds of systems for proving, computing, evaluating, etc.  This
enables us to integrate specific CA tools into the whole machinery
where necessary.

\fixme[comparison to other systems]

\section{Isabelle's knowledge for application in engineering}
Isabelle's features described so far establish a system appealing for
computer scientists, mathematicians and logicians to mechanise their
respective knowledge due to individual interests and in projects of
various size. The Isabelle developer has been continuously integrating
the many contributions to a coherent and manageable system of mechanised
knowledge, providing a base for further development.

\subsection{Preexisting formalisations}

In addition to the datatypes mentioned in \secref{calculus}, the
Isabelle distribution~\footnote{}
and the accompanying Archive of Formal Proofs~\footnote{\url{}}
contain various already formalised knowledge which can be built on,
to name some promising candidates:


\item[Algebra] is developed from groups, rings, fields up to the
fundamental theorem of algebra in the univariate case and Groebner
bases in the multivariate case.

\item[Linear algebra] with executable operations on matrices of
arbitrary dimensions over ordered semirings, elementary linear algebra
on Euclidean spaces, convexity in real vector spaces up to
Gauss-Jordan Elimination for Matrices.

\item[Analysis] includes semicontinuous and continuous functions,
Cauchy's Mean Theorem and the Cauchy-Schwarz Inequality, MacLaurin and
Taylor series, nth roots and the transcendental functions.

\item[Multivariate analysis] concerning Frechet Derivative, Inner
Product Spaces and the Gradient Derivative, Finite-Dimensional Inner
Product Spaces, Multivariate calculus in Euclidean space,
Kurzweil-Henstock Gauge Integration in many dimensions, up to initial
value problems of Ordinary Differential

\item[Probability theory] including Binomial Coefficients,
Permutations, Social Choice Theory (Arrow's General Possibility
Theorem, Sen's Liberal Paradox and May's Theorem) and also
Discrete-Time Markov Chains.

\item[Polynomials] in an univariate and in a multivariate version, the
latter addressing monotonicity on strongly normalizing (monotone)
orders.  \item[Number theory] with primality on $\cal N$, congruence,
unique factorisation, divisibility in monoids and rings, Residue
rings: Euler's theorem and Wilson's theorem, quotient rings.

% \item[Numerals] and their respective arithmetic are all available,
% $\cal N, I, Q, R$ and $\cal C$.  For $\cal R$ there are approximations
% by floating point numbers~
% \footnote{\_Procs/Approximation.html}.


% Following the LCF paradigm all the above knowledge is derived from
% first principles, from the axioms of HOL. The axioms, definitions,
% theorems and proofs are human readable.

This knowledge covers the range of mathematics addressed by most
introductory university courses in engineering sciences. So there is
comparably easy for the envisaged TP-PL prototype to serve in
engineering education. However, why should student learn something
which is neither required in research nor in the practice of
engineering in the respective domain?

Reaching readiness for application seems difficult in both, in
industry as well as in research. TP-PL decided to primarily address
research as shown in the next section.

\subsection{Examples for TP-services useful in research}
%\subsection{Example for an application domain}
A domain where TP-PL seems to be able to serve actual research is
Information theory -- in spite the fact, that the Isabelle theory
\textit{Information.thy} in the release of 2012 covers only the first
50 pages of total 650 in a standard text book~\cite{info-thy-06}: the
final theorems in \textit{Information.thy} are
conditional\_entropy\_less\_eq\_entropy, entropy\_chain\_rule} and

There are two promising applications, the first one is
``non-Shannon-type inequalities''~\cite{non-shannon-01}. This kind of
information theoretic inequalities still need to be treated by hand
(or by a Matlab toolbox~\cite{Ru99a}) while ``Shannon-type
inequalities'' are proved automatically by special purpose
provers~\footnote{}. So
``non-Shannon-type'' still might rely on interactive TP.

Another application is an ``inverse problem'' to the following: Given
a certain measurement device composed from several hardware and
software components, the overall precision of the device can be
calculated. Of practical interest is the problem inversion: Given a
certain precision requested by customers or by standards, how can the
components be optimised in costs and responsiveness by reducing
respective precision such that the precision requested for the
over-all system is still met. This inverse problem can be tackled by a
TP-based program using Isabelle's interval
}, which, after a trial and
error optimisation, would lead to a proof that the ``optimised''
device meets the requirements.

\fixme[Provide a detailed example for the ``inverse problem''.]