On 04/22/2014 12:59 PM, Drew Adams wrote:
>> The SBCL and ECL behavior is what I'd expect from reading the spec, but
>> maybe I misunderstood something.
> 
> Hm.  What part of the spec do you think gives the impression that
> `defmacro' behavior is defined only at top level?

defmacro is specced to "define[] name as a macro by associating a macro
function with that name in the global environment". Like any form, it's
supposed to do that when it's evaluated, and forms inside defuns aren't
evaluated when they're loaded or compiled: they're evaluated when the
defun is called. So you should expect a defmacro inside a defun to have
no effect unti lthe defun is called.

Likewise, if a defmacro appears at top level, it should ordinarily be
evaluated only when the file that contains it is loaded, just like any
other toplevel form. So, without special provisions, defmacro should not
be expanded inside forms that happen to be in the same file.

But this behavior isn't very useful, so as a special case, CL specifies
that "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. Users must ensure
that the body of the macro can be evaluated at compile time if it is
referenced within the file being compiled."

It's because of this special case that a normal defmacro, not wrapped in
an eval-when, has any effect on compilation of forms in the same file. A
defmacro inside a defun isn't covered by this special case, so its
behavior should revert to the normal behavior for forms. SBCL and ECL
implement this model of evaluation. CLISP's behavior appears to be
incorrect here.

The behavior I'm proposing for Emacs is identical to what SBCL and ECL
do. Stefan is proposing that we adopt CLISP behavior.