Date: Thu, 1 Oct 1992 13:16 EDT
From: "T. V. Raman" <·····@cs.cornell.edu>
Lucid seems to behave in an unexpected way if you
1) First compile a function that calls a macro
and then
2) Compile the macro.
After doing the above, calling the function results in an extremely
misleading error message:
Something to the effect that the macro has been called with one less
argument than required.
The bug is yours. Lucid is confused by your non-conformance with the language definition,
which requires that macro definitions precede their usage. From the dpANS CL spec:
-----
3.2.2.3 Semantic Constraints
Conforming code must be structured such so that its results and observable
side-effects are the same whether or not compilation takes place.
...
* Definitions of any referenced macros must be present in the compilation
environment. Any form that is a list beginning with a symbol that does not
name a special operator or a macro defined in the compiation environment
is treated by the compiler as a function call.
...
-----
Lucid is doing exactly this. When it sees your macro call, it doesn't
know it's a macro because it hasn't seen the definition. So it assumes
a function call. Then when you call the function, the code which it
jumps to turns out to be a function, and so is not jumped to correctly.
(I don't know Lucid's implementation, but I'd guess you're probably jumping
into the macroexpander function, since in most implementations such things
take a FORM and ENV as arguments.)
Their error diagnostic could presumably be a little more informative, but
perhaps not without some efficiency cost, which you probably don't want to
pay on stock hardware. In any case, their behavior is well within the bounds
of reasonable behavior.
The moral is to always make sure macro definitions come first.