VERIFY-GUARDS

Before discussing the verify-guards event, we first discuss guard
verification, which can take place at definition time or, later, using
verify-guards. Typically, guard verification takes place at definition
time if a guard (or type, or stobjs) has been supplied explicitly unless
:verify-guards nil has been specified; see defun and see xargs, and
see set-verify-guards-eagerness for how to change this default. The point
of guard verification is to ensure that during evaluation of an expression
without free variables, no guard violation takes place.

Guard verification is intended to guarantee that for any call of a given
function, if its guard holds for that call then the guard will hold
for every function call in the body of that function. Moreover, in order to
avoid guard violations during evaluation of the function's guard itself,
guard verification also is intended to guarantee that the guards are
satisfied for all calls in the guard itself. Consider the following simple
example.

If you evaluate (f t), for example, in the top-level loop, you will (by
default) get a guard error. The point of guard verification is to guarantee
the absence of guard errors, and we start by using this example to illustrate
the proof obligations that guarantee such absence.

The body of the above definition has the following function calls, where the
first is the entire body.

We thus see potentially six conditions to prove, one for each call. The
guards of the function symbols of those calls are t for if and
rationalp, (or (consp x) (equal x nil)) for both (car x) and
(cdr x), and finally that both arguments are rationals for <.
Moreover, we can take advantage of ``contextual assumptions'': the
if-test conditions and the top-level :guard. Thus, for
verify-guards the proof obligation from the body of f is as follows.

But the :guard itself generates a similar sort of proof obligation. Note
that the guard (and (consp x) (integerp (car x))) is really an
abbreviation (i.e. via the macro AND) for the term
(if (consp x) (integerp (car x)) nil). The guard proof obligation for
the guard itself is thus as follows.

All of the above proof obligations are indeed theorems, and guard
verification succeeds for the above definition of f.

The example above illustrates the general procedure for generating the guard
proof obligation. Each function call is considered in the body or guard of
the function, and it is required that the guard is met for that call, under
certain ``contextual assumptions'', which are as follows. In the case of the
body of the named function, it is assumed that the guard holds for that
function on its formal parameters. And in both cases -- the body of the
named function and also its guard -- the governing tests from superior
calls of IF are also assumed.

As mentioned above, if the guard on a function is not t, then guard
verification requires not only consideration of the body under the assumption
that the guard is true, but also consideration of the guard itself. Thus,
for example, guard verification fails in the following example, even though
there are no proof obligations arising from the body, because the guard
itself can cause a guard violation when evaluated for an arbitrary value of
x:

(defun foo (x)
(declare (xargs :guard (car x)))
x)

We turn now to the verify-guards event as a way of verifying the
guards for a function or theorem.

In the General Form above, name is the name of a :logic
function (see defun-mode) or of a theorem or axiom. In the most common case
name is the name of a function that has not yet had its guards
verified, each subroutine of which has had its guards verified. The
values hints, otf-flg, and guard-debug are as described in
the corresponding documentation entries; and doc-string, if
supplied, is a string not beginning with ``:Doc-Section''. The four
keyword arguments above are all optional. To admit this event, the
conjunction of the guard proof obligations must be proved. If that proof is
successful, name is considered to have had its guards verified.

See verify-guards-formula for a utility that lets you view the formula to be
proved by verify-guards, but without creating an event.

If name is one of several functions in a mutually recursive clique,
verify-guards will attempt to verify the guards of all of the
functions.

If name is a theorem or axiom name, verify-guards verifies the
guards of the associated formula. When a theorem has had its guards
verified then you know that the theorem will evaluate to non-nil
in all Common Lisps, without causing a runtime error (other than possibly
a resource error). In particular, you know that the theorem's validity
does not depend upon ACL2's arbitrary completion of the domains of partial
Common Lisp functions.

However, if you go into almost any Common Lisp in which app is defined
as shown and evaluate

(equal (app (app 1 2) 3) (app 1 (app 2 3)))

we get an error or, perhaps, something worse like nil! How can
this happen since the formula is an instance of a theorem? It is supposed
to be true!

It happens because the theorem exploits the fact that ACL2 has completed
the domains of the partially defined Common Lisp functions like car
and cdr, defining them to be nil on all non-conses. The formula
above violates the guards on app. It is therefore ``unreasonable''
to expect it to be valid in Common Lisp.

That is, no matter what the values of a, b and c the formula
above evaluates to t in all Common Lisps (unless the Lisp engine runs out
of memory or stack computing it). Furthermore the above formula is a theorem:

This formula, guarded-assoc-of-app, is very easy to prove from
assoc-of-app. So why prove it? The interesting thing about
guarded-assoc-of-app is that we can verify the guards of the
formula. That is, (verify-guards guarded-assoc-of-app) succeeds.
Note that it has to prove that if a and b are true lists then
so is (app a b) to establish that the guard on the outermost app
on the left is satisfied. By verifying the guards of the theorem we
know it will evaluate to true in all Common Lisps. Put another way,
we know that the validity of the formula does not depend on ACL2's
completion of the partial functions or that the formula is ``well-typed.''

One last complication: The careful reader might have thought we could
state guarded-assoc-of-app as

rather than using the if form of the theorem. We cannot! The
reason is technical: implies is defined as a function in ACL2.
When it is called, both arguments are evaluated and then the obvious truth
table is checked. That is, implies is not ``lazy.'' Hence, when
we write the guarded theorem in the implies form we have to prove
the guards on the conclusion without knowing that the hypothesis is true.
It would have been better had we defined implies as a macro that
expanded to the if form, making it lazy. But we did not and after
we introduced guards we did not want to make such a basic change.

Recall however that verify-guards is almost always used to verify
the guards on a function definition rather than a theorem. We now
return to that discussion.

Verify-guards must often be used when the value of a recursive call
of a defined function is given as an argument to a subroutine that
is guarded. An example of such a situation is given below. Suppose
app (read ``append'') has a guard requiring its first argument to be
a true-listp. Consider

Observe that the value of a recursive call of rev is being passed
into a guarded subroutine, app. In order to verify the guards of
this definition we must show that (rev (cdr x)) produces a
true-listp, since that is what the guard of app requires. How do we
know that (rev (cdr x)) is a true-listp? The most elegant argument
is a two-step one, appealing to the following two lemmas: (1) When x
is a true-listp, (cdr x) is a true-listp. (2) When z is a
true-listp, (rev z) is a true-listp. But the second lemma is a
generalized property of rev, the function we are defining. This
property could not be stated before rev is defined and so is not
known to the theorem prover when rev is defined.

Therefore, we might break the admission of rev into three steps:
define rev without addressing its guard verification, prove some
general properties about rev, and then verify the guards. This can
be done as follows:

The ACL2 system can actually admit the original definition of
rev, verifying the guards as part of the defun event. The
reason is that, in this particular case, the system's heuristics
just happen to hit upon the lemma true-listp-rev. But in many
more complicated functions it is necessary for the user to formulate
the inductively provable properties before guard verification is
attempted.

Remark on computation of guard conjectures and evaluation. When ACL2
computes the guard conjecture for the body of a function, it
evaluates any ground subexpressions (those with no free variables), for
calls of functions whose :executable-counterpartrunes are
enabled. Note that here, ``enabled'' refers to the current global
theory, not to any :hints given to the guard verification
process; after all, the guard conjecture is computed even before its initial
goal is produced. Also note that this evaluation is done in an environment
as though :set-guard-checking :all had been executed, so that we can
trust that this evaluation takes place without guard violations;
see set-guard-checking.

If you want to verify the guards on functions that are built into ACL2,
you will first need to put them into :logic mode.
See verify-termination, specifically the ``Remark on system functions'' in
that documentation.