If the argument is not supplied, then this command sets the
current proof-checker theory (see below for explanation) to agree
with the current ACL2 theory. Otherwise, the argument should be a
theory expression, and in that case the proof-checker theory is set
to the value of that theory expression.

The current proof-checker theory is used in all calls to the ACL2 theorem
prover and rewriter from inside the proof-checker. Thus, the most recent
in-theory instruction in the current state-stack has an effect in the
proof-checker totally analogous to the effect caused by an in-theory hint
or event in ACL2. All in-theory instructions before the last are
ignored, because they refer to the current theory in the ACL2 state,
not to the existing proof-checker theory. For example:

Thus (in-theory (enable bar)) modifies the current theory of the current
ACL2 world. So for example, suppose that foo is disabled outside the
proof checker and you execute the following instructions, in this order.

(in-theory (enable foo))
(in-theory (enable bar))

Then after the second of these, bar will be enabled in the proof-checker,
but foo will be disabled. The reason is that
(in-theory (enable bar)) instructs the proof-checker to modify the
current theory (from outside the proof-checker, not from inside the
proof-checker) by enabling bar.

Note that in-theory instructions in the proof-checker have no effect
outside the proof-checker's interactive loop.

If the most recent in-theory instruction in the current state of the
proof-checker has no arguments, or if there is no in-theory
instruction in the current state of the proof-checker, then the
proof-checker will use the current ACL2 theory. This is true even
if the user has interrupted the interactive loop by exiting and
changing the global ACL2 theory. However, if the most recent
in-theory instruction in the current state of the proof-checker had
an argument, then global changes to the current theory will have no
effect on the proof-checker state.