The compiler will produce this warning:
File: /usr/me/stuff.lisp In: DEFUN FOO (ZOQ Y) --> ROQ PLOQ + ==> Y Warning: Result is a SYMBOL, not a NUMBER.
In this example we see each of the six possible parts of a compiler error message:
File: /usr/me/stuff.lisp
This is the file that
the compiler read the relevant code from. The file name is
displayed because it may not be immediately obvious when there is an
error during compilation of a large system, especially when
with-compilation-unit
is used to delay undefined warnings.
In: DEFUN FOO
This is the definition or
top-level form responsible for the error. It is obtained by taking
the first two elements of the enclosing form whose first element is
a symbol beginning with “DEF
”. If there is no enclosing
defmumble, then the outermost form is used. If there are
multiple defmumbles, then they are all printed from the
out in, separated by =>
’s. In this example, the problem
was in the defun
for foo
.
(ZOQ Y)
This is the original source form
responsible for the error. Original source means that the form
directly appeared in the original input to the compiler, i.e. in the
lambda passed to compile
or the top-level form read from the
source file. In this example, the expansion of the zoq
macro
was responsible for the error.
--> ROQ PLOQ +
This is the processing path
that the compiler used to produce the errorful code. The processing
path is a representation of the evaluated forms enclosing the actual
source that the compiler encountered when processing the original
source. The path is the first element of each form, or the form
itself if the form is not a list. These forms result from the
expansion of macros or source-to-source transformation done by the
compiler. In this example, the enclosing evaluated forms are the
calls to roq
, ploq
and +
. These calls resulted
from the expansion of the zoq
macro.
==> Y
This is the actual source responsible for
the error. If the actual source appears in the explanation, then we
print the next enclosing evaluated form, instead of printing the
actual source twice. (This is the form that would otherwise have
been the last form of the processing path.) In this example, the
problem is with the evaluation of the reference to the variable
y
.
Warning: Result is a SYMBOL, not a NUMBER.
This is
the explanation the problem. In this example, the problem is
that y
evaluates to a symbol
, but is in a context
where a number is required (the argument to +
).
Note that each part of the error message is distinctively marked:
File:
and In:
mark the file and definition,
respectively.
-->
.
==>
line. This is like the
“macroexpands to” notation used in Common Lisp: The Language.
Error:
, Warning:
, or
Note:
.
Each part of the error message is more specific than the preceding one. If consecutive error messages are for nearby locations, then the front part of the error messages would be the same. In this case, the compiler omits as much of the second message as in common with the first. For example:
File: /usr/me/stuff.lisp In: DEFUN FOO (ZOQ Y) --> ROQ ==> (PLOQ (+ Y 3)) Warning: Undefined function: PLOQ ==> (ROQ (PLOQ (+ Y 3))) Warning: Undefined function: ROQ
In this example, the file, definition and original source are identical for the two messages, so the compiler omits them in the second message. If consecutive messages are entirely identical, then the compiler prints only the first message, followed by:
[Last message occurs repeats times]
where repeats is the number of times the message was given.
If the source was not from a file, then no file line is printed. If the actual source is the same as the original source, then the processing path and actual source will be omitted. If no forms intervene between the original source and the actual source, then the processing path will also be omitted.