On 04/22/2014 01:41 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,
> 
> Yes, anywhere and anywhen it's evaluated, including from a file at any
> level.  And including when invoked from running code.  And including
> `defmacro' forms that are generated and eval'd on the fly.

That goes without saying.

> But I do see now that you allowed for `progn' contexts, at least.
> I guess you meant any context, like progn, which evaluates the
> `defmacro' at load or compile time.
> 
> It does not say anything about `defmacro' inside a defun signaling a
> compile-time error, as opposed to doing what you write above: "have no
> effect until the defun is called".  A priori, when the defun is called
> the `defmacro' inside it should be evaluated, defining the macro
> normally, no?

Neither did I. I was imprecise: the code I mentioned compiles without
error. It signals an error at runtime because there is no function
called `bar'. The function is trying to call `bar' because the macro
`bar' wasn't expanded during compilation.

> It says clearly that IF you expect the macro to be available to code
> in the same file at compile time for that file, THEN you must ensure
> that it gets evaluated at compile time.  If not, then not.
> 
>> 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.
> 
> Which is what?  Why isn't it that the embedded `defmacro' would, as you
> said "have no effect until the defun is called"?

"No effect until the defun is called" is the correct behavior.

>> SBCL and ECL implement this model of evaluation. CLISP's behavior
>> appears to be incorrect here.
> 
> I don't see that either of those behaviors realizes the exclusive truth
> here.  All I see that passage saying is that you must not expect a
> `defvar' embedded in a defun to have an effect, at compile time, on
> subsequent code located in the same file.  I don't see that as a call
> to raise a compile-time error.

There is no compile-time error; sorry for the misunderstanding.