• Top
    • Documentation
    • Books
    • Boolean-reasoning
    • Projects
    • Debugging
      • Break-rewrite
        • Monitor
        • Brr
        • Brr-commands
        • Dmr
        • With-brr-data
        • Geneqv
        • Refinement-failure
        • Break-lemma
        • Why-brr
        • Brr@
          • Cw-gstack
          • Ok-if
          • Windows-installation
          • Brr-near-missp
          • Monitored-runes
          • Unmonitor
          • Monitor!
        • Proof-builder
        • Accumulated-persistence
        • Cgen
        • Forward-chaining-reports
        • Proof-tree
        • Print-gv
        • Dmr
        • With-brr-data
        • Splitter
        • Guard-debug
        • Set-debugger-enable
        • Redo-flat
        • Time-tracker
        • Set-check-invariant-risk
        • Removable-runes
        • Efficiency
        • Explain-near-miss
        • Tail-biting
        • Failed-forcing
        • Sneaky
        • Invariant-risk
        • Failure
        • Measure-debug
        • Dead-events
        • Compare-objects
        • Prettygoals
        • Remove-hyps
        • Type-prescription-debugging
        • Pstack
        • Trace
        • Set-register-invariant-risk
        • Walkabout
        • Disassemble$
        • Nil-goal
        • Cw-gstack
        • Set-guard-msg
        • Find-lemmas
        • Watch
        • Quick-and-dirty-subsumption-replacement-step
        • Profile-all
        • Profile-ACL2
        • Set-print-gv-defaults
        • Minimal-runes
        • Spacewalk
        • Try-gl-concls
        • Near-misses
      • Std
      • Proof-automation
      • Macro-libraries
      • ACL2
        • Theories
        • Rule-classes
        • Proof-builder
        • Recursion-and-induction
        • Hons-and-memoization
        • Events
        • Parallelism
        • History
        • Programming
        • Operational-semantics
        • Real
        • Start-here
        • Debugging
          • Break-rewrite
            • Monitor
            • Brr
            • Brr-commands
            • Dmr
            • With-brr-data
            • Geneqv
            • Refinement-failure
            • Break-lemma
            • Why-brr
            • Brr@
              • Cw-gstack
              • Ok-if
              • Windows-installation
              • Brr-near-missp
              • Monitored-runes
              • Unmonitor
              • Monitor!
            • Proof-builder
            • Accumulated-persistence
            • Cgen
            • Forward-chaining-reports
            • Proof-tree
            • Print-gv
            • Dmr
            • With-brr-data
            • Splitter
            • Guard-debug
            • Set-debugger-enable
            • Redo-flat
            • Time-tracker
            • Set-check-invariant-risk
            • Removable-runes
            • Efficiency
            • Explain-near-miss
            • Tail-biting
            • Failed-forcing
            • Sneaky
            • Invariant-risk
            • Failure
            • Measure-debug
            • Dead-events
            • Compare-objects
            • Prettygoals
            • Remove-hyps
            • Type-prescription-debugging
            • Pstack
            • Trace
            • Set-register-invariant-risk
            • Walkabout
            • Disassemble$
            • Nil-goal
            • Cw-gstack
            • Set-guard-msg
            • Find-lemmas
            • Watch
            • Quick-and-dirty-subsumption-replacement-step
            • Profile-all
            • Profile-ACL2
            • Set-print-gv-defaults
            • Minimal-runes
            • Spacewalk
            • Try-gl-concls
            • Near-misses
          • Miscellaneous
          • Output-controls
          • Macros
          • Interfacing-tools
        • Interfacing-tools
        • Hardware-verification
        • Software-verification
        • Math
        • Testing-utilities
      • Break-rewrite

      Brr@

      To access context sensitive information within break-rewrite

      Example:
      (brr@ :target)      ; the term being rewritten
      (brr@ :unify-subst) ; the unifying substitution
      
      General Form:
      (brr@ :symbol)

      where :symbol is one of the keywords displayed below. This utility may be most useful for system hackers; see brr-commands for queries that are more at a user level. In particular, keywords marked below with * probably require an implementor's knowledge of the system to use effectively. They are supported but not well documented. More is said on this topic following the table. For background on the notion of ``translated'' term, see term.

      :symbol             (brr@ :symbol)
      -------             ---------------------
      
      :target             the term to be rewritten.  This term is an
                          instantiation of the left-hand side of the
                          conclusion of the rewrite-rule being broken.
                          This term is in translated form!  Thus, if
                          you are expecting (equal x nil) -- and your
                          expectation is almost right -- you will see
                          (equal x 'nil); similarly, instead of (cadr a)
                          you will see (car (cdr a)).  In translated
                          forms, all constants are quoted (even nil, t,
                          strings and numbers) and all macros are
                          expanded.
      
      :unify-subst        the substitution that, when applied to :target,
                          produces the left-hand side of the rule being
                          broken.  This substitution is an alist pairing
                          variable symbols to translated (!) terms.
      
      :wonp               t or nil indicating whether the rune was
                          successfully applied.  (brr@ :wonp) returns
                          nil if evaluated before :EVALing the rule.
      
      :rewritten-rhs      the result of successfully applying the rewrite
                          rule or else nil if (brr@ :wonp) is nil.  The
                          result of successfully applying the rule is
                          always a translated (!) term and is never nil.
      
      :poly-list          the result of successfully applying the linear
                          rule or else nil if (brr@ :wonp) is nil.  This
                          result represents the list of polynomials
                          produced by the rule application.  The leading
                          term of each polynomial is enclosed in an extra
                          set of parentheses.
      
      :pot-list        *  the pot-list, which is the set of polynomials
                          that are assumed in the current context,
                          organized by maximal term.  Each polynomial in
                          the list is a linear-pot record.
      
      :failure-reason     some non-nil lisp object indicating why the rule
                          was not applied or else nil.  Before the rule is
                          :EVALed, (brr@ :failure-reason) is nil.  After
                          :EVALing the rule, (brr@ :failure-reason) is nil
                          if (brr@ :wonp) is t.  Rather than document the
                          various non-nil objects returned as the failure
                          reason, we encourage you simply to evaluate
                          (brr@ :failure-reason) in the contexts of interest.
                          Alternatively, study the ACL2 function tilde-@-
                          failure-reason-phrase.
      
      :lemma           *  the rewrite rule being broken.  For example,
                          (access rewrite-rule (brr@ :lemma) :lhs) will
                          return the left-hand side of the conclusion
                          of the rule.
      
      :type-alist      *  a display of the type-alist governing :target.
                          Elements on the displayed list are of the form
                          (term type), where term is a term and type
                          describes information about term assumed to hold in
                          the current context.  (See also the documentation for
                          type-alist.)  The type-alist may be used to determine
                          the current assumptions, e.g., whether A is a CONSP.
      
      :geneqv          *  the generated equivalence relation that specifies
                          what equivalence relations may be used to rewrite
                          the target.  (See the documentation for geneqv and
                          refinement-failure.)
      
      :ancestors       *  a stack of frames indicating the backchain history
                          of the current context.  The theorem prover is in
                          the process of trying to establish each hypothesis
                          in this stack.  Thus, the negation of each hypothesis
                          can be assumed false.  Each frame also records the
                          rules on behalf of which this backchaining is being
                          done and the weight (function symbol count) of the
                          hypothesis.  All three items are involved in the
                          heuristic for preventing infinite backchaining.
                          Exception:  Some frames are ``binding hypotheses''
                          (equal var term) or (equiv var (double-rewrite term))
                          that bind variable var to the result of rewriting
                          term.  The ACL2 source code has a definition
                          (defrec ancestor ...) that may provide some relevant
                          insight.
      
      :initial-ttree   *  the initial and (after :EVAL) final tag trees,
      :final-ttree        respectively.  (Tag trees are low-level data structures
                          that store lemmas used and other information, as
                          documented in topic TTREE.)
      
      :gstack          *  the current goal stack.  The gstack is maintained
                          by rewrite and is the data structure printed as the
                          current ``path.''  Thus, any information derivable
                          from the :path brr command is derivable from gstack.
                          For example, from gstack one might determine that
                          the current term is the second hypothesis of a
                          certain rewrite rule.

      In general brr@-expressions are used in break conditions, the expressions that determine whether interactive breaks occur when monitored runes are applied. See monitor. For example, you might want to break only those attempts in which one particular term is being rewritten or only those attempts in which the binding for the variable a is known to be a consp. Such conditions can be expressed using ACL2 system functions and the information provided by brr@. Unfortunately, digging some of this information out of the internal data structures may be awkward or may, at least, require intimate knowledge of the system functions. But since conditional expressions may employ arbitrary functions and macros, we anticipate that a set of convenient primitives will gradually evolve within the ACL2 community. It is to encourage this evolution that brr@ provides access to the *'d data.