[FOM] Adventures in Formalization

Natarajan Shankar shankar at csl.sri.com
Sat Sep 19 18:15:08 EDT 2015



Dear Harvey: I read your FOM postings on ``Adventures in Formalization'' 
with interest, and
sympathize with the spirit of your remarks and quite a few of the 
details.  Here's some
feedback on the Beautiful Formalization Project (BFP) from the 
perspective of our
PVS proof assistant whose design goals closely match several of the 
criteria that you have outlined.

By way of background, for at least thirty years now, it has been the 
case that most of the
proofs from the mathematical literature prior to 1950, say, have not 
been particularly
challenging to machine-check even for proof assistants with fairly weak 
automation.  There
are several substantive proof libraries that would enlighten your 
``typical skeptical
mathematician''.  The more interesting challenge is to construct 
formalizations that are
beautiful, so that even the ``nuanced doubters'' are convinced that 
there is good value to
be derived from the formalization process and the availability of formal 
mathematical
content supported by powerful inference algorithms.

THEOREM STATEMENTS: You are indeed correct in asserting that the 
readability of the formal
presentation is critical.  This is especially the case in computing 
where many errors lurk
in the formalization of informal ``requirements''.  On this dimension, 
formal mathematics
with mechanization can go considerably beyond informal mathematics to 
support a precise yet
natural mathematical vernacular.  As a simple example, I always took it 
on faith, as
virtually every textbook treatment does, that (n choose k) = n! 
/k!(n-k)! defines an
integer.  It helps to have a typechecker tell you that this isn't 
entirely obvious, and
that furthermore k should be at most n, and that the division is fine 
because the product
of two factorials is never zero.  (Free logics of the kind you suggest 
turn out to be quite
a bit more painful than clearly restricting the domain of the 
denominator to nonzero
numbers.)

ABSOLUTE INFALLIBILITY: As Paulson already mentioned, there already are 
some quite impressive
attempts to shrink the trusted core.  More below.

GOLD STANDARD: Over the past few years, I have been working 
intermittently on a project
called the Kernel of Truth (KoT) to bridge the gap between a usable 
formal language with
efficient mechanized inference and a small trusted kernel for exactly 
the kind of core
logics you have in mind.  The premise of the project is that a typical 
proof engineer
wishes to work on a domain-friendly formalism with domain-friendly 
automation that might be
untrusted and even experimental.  Typically, a lot of this proof work is 
exploratory but
every now and then, claims need to be certified.  For this, the 
untrusted proof engines
generate certificates and these certificate/claim pairs are checked 
using checkers that
have been verified relative to the trusted kernel.  This way the 
certificates need not be
expanded down to proofs at the kernel level, as is the case in the LCF 
approach. Also,
certificate checkers are considerably easier to verify than your typical 
SAT/SMT solver.

SELF PROVING: This was a hugely important design consideration in PVS 
when we were
developing the system twenty five years ago.  Many features of the type 
system work
effectively only when there is adequate automation for the trivial 
inference steps.  We
wanted proofs to be developed through a dialogue at roughly the same 
level of detail and
proof hints as a convincing informal exposition.  Trivial inference 
steps and
simplifications should be handled by decision procedures for 
propositional logic, equality
reasoning, and for theory combinations including linear arithmetic. Most 
of the time is
spent on exploratory proof attempts that fail, and they fail because 
either the statement
is unprovable or the proof is incorrect.  We therefore tried to use the 
automation to
simplify the statement to a point where the error is apparent. Overall, 
the user guides
the proof by suggesting induction, non-obvious/non-local case splits, 
lemmas, and
instantiations.  The proof dialogue is based on HAVE/WANT-style sequents 
with user-supplied
proof hints that drive the proof goal into easily decidable subgoals.  
However, obviousness
can be a moving target.  For example, the first couple of cases in a 
proof could be
nontrivial, but the remaining cases may not hold any new surprises. 
There is plenty of
scope for improving the automation to expand the range of obvious 
inferences, particularly
to cover obvious inferences involving quantifier instantiation and 
nonlinear arithmetic
equality and inequality constraints.

In summary, modern proof assistants have experimented with many ideas 
that are similar to
the ones you have proposed and there is a large body of accumulated 
evidence that can
definitely inform your thinking on BFP.  Conversely, it would be great 
to have your
feedback pinpointing opportunities for radical improvements.

Best regards,
Shankar



More information about the FOM mailing list