Next: Error Severity
Up: Interpreting Error Messages
Previous: The Original and Actual
  Contents
  Index
The Processing Path
processing path
macroexpansion
source-to-source transformation
The processing path is mainly useful for debugging macros, so if you don't
write macros, you can ignore the processing path. Consider this example:
(defun foo (n)
(dotimes (i n *undefined*)))
Compiling results in this error message:
In: DEFUN FOO
(DOTIMES (I N *UNDEFINED*))
-> DO BLOCK LET TAGBODY RETURN-FROM
==>
(PROGN *UNDEFINED*)
Warning: Undefined variable: *UNDEFINED*
Note that do appears in the processing path. This is because dotimes
expands into:
(do ((i 0 (1+ i)) (#:g1 n))
((>= i #:g1) *undefined*)
(declare (type unsigned-byte i)))
The rest of the processing path results from the expansion of do:
(block nil
(let ((i 0) (#:g1 n))
(declare (type unsigned-byte i))
(tagbody (go #:g3)
#:g2 (psetq i (1+ i))
#:g3 (unless (>= i #:g1) (go #:g2))
(return-from nil (progn *undefined*)))))
In this example, the compiler descended into the block,let, tagbody and return-from to reach theprogn printed as the actual source. This is a place where the
``actual source appears in explanation'' rule was applied. The
innermost actual source form was the symbol *undefined* itself,
but that also appeared in the explanation, so the compiler backed out
one level.
Next: Error Severity
Up: Interpreting Error Messages
Previous: The Original and Actual
  Contents
  Index
Peter Van Eynde
2001-03-08