Re: [Sbcl-devel] timely definition of non-top level macro

[Stas B. <sta...@gm...>]

"Kouskoulas, Yanni A." <Yan...@jh...> writes:

> During the process of porting some code from clisp to sbcl, I encountered some unexpected behavior that is potentially a bug. It is at the very least a difference in the two implementations. After searching through the archives and the BUGS file, and I could not find it discussed, so if I thought I'd bring it to the attention of sbcl-devel.
>
> When loading a form such as
>
> (let ((a 0))
>
>   (defmacro Q (g)
>     17)
>
>   (defun R ()
>     (Q (not-a-function-call))))
>
> sbcl produces some messages and warnings that imply to me that the macro Q is being defined *after* the function R has been defined and the let is closed. This means that when R is being defined, the compiler assumes that Q is a function. When the let closes, Q is defined as a macro, but at that point it is to late for its macroexpansion in R. Running (R) produces an error as it attempts to call the non-existent function, (not-a-function-call) in an effort to evaluate the arguments of the (also non-existent) function Q. This behavior is unexpected, because the form that defines Q is before the form that binds R, and usually the forms in a let are evaluated in sequence.
>
> The clisp implementation that I have available behaves as I would expect based on my reading of cltl2, defining Q and then expanding the macro correctly when defining R, in the sequence provided by the code. Running (R) in clisp produces 17 as expected. The sbcl-style behavior (the error) seems very unexpected to me. What is the reason sbcl is doing this?
>
> Thanks in advance for any explanations.
http://www.lispworks.com/reference/HyperSpec/Body/m_defmac.htm :
"If a defmacro form appears as a top level form, the compiler must store the macro definition at compile time, so that occurrences of the
macro later on in the file can be expanded correctly."

-- 
With best regards, Stas.