[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as tople
From: |
Daniel Colascione |
Subject: |
Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling |
Date: |
Tue, 22 Apr 2014 14:05:27 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 |
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.
signature.asc
Description: OpenPGP digital signature
- Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, (continued)
- Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, Stefan Monnier, 2014/04/22
- Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, Daniel Colascione, 2014/04/22
- Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, Daniel Colascione, 2014/04/22
- Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, Stefan Monnier, 2014/04/22
- Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, Daniel Colascione, 2014/04/22
- RE: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, Drew Adams, 2014/04/22
- Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, Daniel Colascione, 2014/04/22
- RE: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, Drew Adams, 2014/04/22
- Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, Daniel Colascione, 2014/04/22
- RE: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, Drew Adams, 2014/04/22
- Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling,
Daniel Colascione <=
- RE: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, Stephen J. Turnbull, 2014/04/22
- Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, Stefan Monnier, 2014/04/22
- Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, Stefan Monnier, 2014/04/22
- Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling, Daniel Colascione, 2014/04/22