Major Section: RULE-CLASSES
This documentation describes ACL2's tau system, a kind of ``type checker,''
and the :tau-system
rule class. This doc topic is the main source of
information about the tau system and discusses both the general idea and the
specifics of :tau-system
rules. There happens to be a function named
tau-system
, defined as the identity function. Its only role is to
provide the rune (:EXECUTABLE-COUNTERPART TAU-SYSTEM)
, which is used
to enable and disable the tau system. Otherwise the function tau-system
has no purpose and we recommend that you avoid using it so you are free to
enable and disable the tau system.
Background on the Tau System
Because ACL2 is an untyped language it is impossible to type check it. All
functions are total. An n-ary function may be applied to any combination
of n ACL2 objects. Nevertheless, the system provides a variety of
monadic Boolean function symbols, like natp
, integerp
,
alistp
, etc., that recognize different ``types'' of objects at runtime.
Users typically define many more such recognizers for domain-specific
``types.'' Because of the prevalence of such ``types,'' ACL2 must frequently
reason about the inclusion of one ``type'' in another. It must also reason
about the consequences of functions being defined so as to produce objects of
certain ``types'' when given arguments of certain other ``types.''
Because the word ``type'' in computer science tends to imply syntactic or semantic restrictions on functions, we avoid using that word henceforth. Instead, we just reason about monadic Boolean predicates.
The tau system consists of both a data base and an algorithm for using the
data base. The data base contains theorems that match certain schemas allowing
them to be stored in the tau data base. Roughly speaking the schemas encode
``inclusion'' and ``exclusion'' relations, e.g., that natp
implies integerp
and that integerp
implies not consp
, and they encode ``signatures'' of
functions, e.g., theorems that relate the output of a function to the input,
provided only tau predicates are involved.
By ``tau predicates'' we mean the application of a monadic Boolean, the
equality of something to a quoted constant, or the negation of such a term.
Thus (natp i)
, (not (consp x))
, (equal tag 'ARRAY-HEADER)
and
(not (eq op 'SKIP))
are tau predicates. The tau system recognizes several
variants of EQUAL
.
The tau algorithm is a decision procedure for the logical theory described (only) by the rules in the data base. The decision procedure can be enabled or disabled. It is enabled by default. You can disable it globally using either of the following equivalent forms (see theories, in particular the discussion of runic designators).
(in-theory (disable (:executable-counterpart tau-system))) (in-theory (disable (tau-system)))
The data base contains rules derived from theorems stated by the user. Unlike a type system, the tau system cannot automatically infer relations between types or the signatures of functions. Such rules must be stated by the user. Furthermore, only theorems matching certain schemas can be stored in the tau data base.
The data base can be populated with new tau facts via either of two
mechanisms depending on a mode controlled by tau-status
or,
alternatively, set-tau-auto-mode
. When in ``manual'' mode, the data
base is extended only when (suitably shaped) theorems tagged with the rule
class :tau-system
are proved. When in ``automatic'' mode, the data base
is extended whenever any (suitably shaped) theorem of any rule class is
proved. The system is in automatic mode by default -- the tau data base is
implicitly extended every time a suitable theorem is proved and stored as
any kind of rule.
Unlike other high-level deduction algorithms in ACL2, the tau system does not keep track of the names (runes) of the rules it is using. To prevent the tau system from using a rule, you must regenerate the tau data base with that rule disabled.
We now give a more technical description of the tau system.
Technical Details
There are two ``modes'' controlling the tau system: one controls whether or
not the algorithm is employed in theorem proving, the other controls whether
the data base is built only from :tau-system
rules (``manual'' mode) or
from any rule of suitable form (``automatic'' mode). Both modes may be set
by tau-status
; see tau-status.
However, to be effective, the tau system must be ``programmed'' with rules. These rules are generally either statements of establishing that one monadic Boolean implies another or statements (e.g., ``type inclusion or exclusion'') or statements about the signatures of functions expressed in terms of monadic Boolean predicates about the inputs and output of functions (e.g., ``signatures'').
If you have not provided such rules, you are likely to notice little difference between having the tau system enbled or disabled -- in fact, if anything, having it enabled without a coherent set of rules is liable to cause more trouble than it is worth because an incoherent set of rules will make the system seem to act in an arbitrary way.
See rule-classes for a general discussion of rule classes and how they are used to build rules from formulas.
Important Note: ACL2 does not track or report the use of tau rules. You
cannot disable them individually! The tau system will evaluate monadic
Boolean functions on constants, even when the executable counterparts of
those functions are disabled! You can shut off the whole tau system by
disabling the rune (:EXECUTABLE-COUNTERPART TAU-SYSTEM)
, locally for a
subgoal (using an :in-theory
hint (see hints) or globally (using the
in-theory
event or the tau-status
macro).
Many different formula shapes are recognized as :tau-system
rules. In
addition, there is a mode in which ACL2 will automatically make a
:tau-system
rule out of any suitable defun
or defthm
event.
See set-tau-auto-mode.
The shapes of the :
corollary
formulas from which :tau-system
rules are built are listed below. Where distinct variable symbols appear in
the schemas below you must write distinct variable symbols. Where predicate
letters appear, e.g., p
, p2
, and q
, you must write monadic
Boolean function symbols or equalities in which one argument is an explicit
constant. Furthermore, you may optionally negate the predicates. By
``Boolean'' we mean not only that the function return T
or NIL
but
that it not be constantly T
or constantly NIL
, and that its Boolean
nature was identified by ACL2 when the function was defined or that a
suitable :
tau-system
or (when the tau system is in automatic mode,
:
type-prescription
) lemma has been proved about it. By
``equalities'' we mean calls of EQUAL
, EQ
, EQL
, and
=
. We include in italics below our internal name for each schema
so that we can document their use.
For example the schema called a ``Simple'' tau rule below matches both
(implies (natp i) (integerp i)) (implies (natp j) (not (consp j)))and the second schema, called a ``Conjunctive'' tau rule, matches
(implies (and (not (equal z nil)) (true-listp z)) (consp z))Note that the Simple rules capture ``type inclusion'' and ``type exclusion.'' Conjunctive rules allow us to infer ``types'' from (conjunctive) combinations of ``types.'' Signature rules, shown below, are used in the obvious way.
General Forms: Boolean: (booleanp (fn v)) Simple: (implies (p v) (q v)) Conjunctive: (implies (and (p1 v) ... (pk v)) (q v)), ; Here k must exceed 1. Signature Form 1: (implies (and (p1 x1) (p2 x2) ...) ; See Note below. (q (fn x1 x2 ...))) Signature Form 2: (implies (and (p1 x1) (p2 x2) ...) ; See Note below. (q (mv-nth 'n (fn x1 x2 ...)))) Big Switch: (equal (fn . formals) body), ; See Note below. MV-NTH Synonym: ; Extend Signature Form 2 to (equal (nth-alt x y) (mv-nth x y)) or ; apply not only to mv-nth, but when (equal (mv-nth x y) (nth-alt x y)) ; mv-nth is replaced by nth-alt.
Note on the Boolean Form: When a :tau-system
rule of this form is proved,
it makes fn
one of the monadic Boolean predicate symbols that the tau
system tracks. This does not inform type-set
that fn
is a Boolean
function! To do that, you should make the formula a
:
type-prescription
rule also. If you have the tau system in
automatic mode (see set-tau-auto-mode), the :type-prescription
rule will
suffice for both purposes.
Note on the Signature Forms: Each of the hypotheses must be a tau-style
predicate (monadic Boolean or equality-with-constant), possibly negated,
about a single variable. But there may be multiple hypotheses about a given
variable. For example, one might include both that (NATP x1)
and
(NOT (EQUAL x1 23))
. Any hypothesis containing a variable other than the
x1
, ..., xn
is ignored.
Note on the Big Switch Form: body
, above, must be a ``big switch'' term,
i.e., one that case splits on tau predicates about a single variable and
produces a term not involving that variable. Since (EQUAL X 'LOAD)
is
considered tau predicate, a simple example of a big switch is a CASE
expression in which a variable is compared successively to a sequence of
symbols. Only the first big switch equation for a given function symbol
fn
is stored!
Note on the MV-NTH Synonym Forms: These forms
To see what the tau system ``knows'' about a given function symbol see tau-data. To see the entire tau data base, see tau-data-base. To regenerate the tau data base using only the runes listed in the current enabled theory, see regenerate-tau-data-base.
Think of the tau system as being a fast, complete theorem prover that only deals with axioms of the above form. We do not provide any other documentation of the tau system at this time!