Mail by Silvio Ranise 24/09/2004
---------------------------------------------------
Dear All,
Calogero told me that last GECCOO meeting was quite an exciting one
and this makes me even more sad not to have the chance to be
there... He also told me that there were questions about the actual
situation of haRVey and the possibility to use a new version. To
answer these questions and to foster the exchange of ideas, here is a
list describing the new features we have integrated in haRVey and that
should make it more desirable:
- zChaff is now available as an alternative to BDDs
- support to discharge many proof obligations with the same back ground
theory
- quantifier handling: there is no more need of the external tool rvqe
to handle quantified formuale. We have re-implemented the algorithm in C
and incorporated it in rvc: so, while you compile a proof obligation, it also
takes care of quantifiers. The program is now very fast. We have also
designed an alternative way to handle quantifier but its implementation
is not yet tested and needs further preliminary tests before being included
in a release.
- arithmetic (!): we have a first version which seem to work but from time
to time it seems to unnecessarely report satisfiability when the formula
is unsatisfiable... This is due to a strange interplay between the
strategy to perform the saturation by the E prover, the decision procedure
for arithmetic, and the protocol we have designed to make them cooperate.
This is an issue which requires further investigations, mainly by
experimentation.
So, we really need proof obligations from you all.
- theory "simplification": when considering the theory you have to model the
various aspects of the Java language, you see that only a small fraction of
it is used when discharging a proof obligation. So, we devised and
implemented a pre-processing step which heuristically squeezes the theory by
throwing away unnecessary axioms.
While the algorithm guarantees that if a formula is provable with the
original theory is also provable with the squeezed theory, it is not guaranted
that the squeezed theory is the smallest possible.
In this case, we were able to test the technique on two sets of proof
obligations coming from two program verification efforts. The results
are quite encouraging and for one of the two case studies, our system
performs much better than the one designed by the author providing the
proof obligations. Needless to say, we will be more than happy to test
this technique on the proof obligations that you will provide us.
Also, to push further the idea on the minimization of the background
theory, we have recently designed an extended input syntax for the
system which allows to provide more structure to the theory so that
the algorithm for the simplification can perform more aggressive
simplification by exploiting such a structure. However, don't worry
the parser is backward compatible so whatever you have in the original
syntax of the system will continue to work with the extended one.
- definition unfolding: one of the problem with superposition is that
it does not like handling formule whose main connective is a
biconditional. This is the case for definitions, e.g. formulae of the
form \forall x.(P(x) <-> body), where body is a 1st order formula not
containing P and whose only free var is x. So, we have implemented a
pre-processing technique which looks for such formulae in the
background theory and unfolds them in the formula to be proved. This
technique greatly contribute to the success of the system on one of
the two case studies mentioned above for the theory minimization
technique. For the other case study, the result is not so good:
further investigations await us in this respect and again here we are
looking forward for more proof obligations coming from you all.
After this list of feature, I hope that those interested among you (I
apologize to the others to have added yet another spam to their
mailboxes) are now motivated to use the new version of the system.
So, how can you get it? Well, David is packing an alpha version of
the system which will be ready very soon. The problem is that most of
the new features are not yet documented so there is a need to give a
minimal description of each one so that you can use them successfully.
As soon as it is ready, I will put it somewhere on the web so that you
can download it.
Indeed, we are keen to receive your feedback and criticisms about
using the system but also we really need proof obligations so that we
get the feeling of which functionality is really needed.
So far, we somehow failed to build a database of proof obligations
arising in the verification of Java programs. This is the key step to
fulfill one of the objective we have promised in the GECCOO proposal:
the characterization of new decidable theories which are important in
program verification toghether with decision procedures for them. If
we do not know how the formulae look like, we certanly won't be able
to give syntactic characterization for them, and ultimiately we won't
be able to define the theories to which they belong. So, in my view
and as I argued above also for the successful fulfillment of one of
the objectives of the project, it is crucial that you provide us as
much proof obligations as possible.
Let me tell you my recent experience. I collaborated with F. Mehta
(one of Nipkow's PhD student) on the mechanization of its proof of
Shorr-Waite algorithm. We identified one of the key lemma and tried
haRVey on it (after translating the lemma from HOL to FOL). The system
was able to discharge the proof obligations necessary to prove the
lemma deriving from the application of the induction principle. More
recently, with Calogero Zarba, we were able to come up with a theory
(whose decidability we are working on) in which such proof obligations
can be expressed and proved automatically by an available decision
procedure. I think that we shall strive to obtain similar results
from our collaborations.
I am sorry for the length of the email and I wish you a pleasant week end.
Best regards,
Silvio.