Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling

[Daniel Colascione]

On 04/21/2014 07:09 PM, Stefan Monnier wrote:
>> Any macro that expands to something like this:
>> (progn (defmacro abc (arg) 1) (defun def () (abc 2)))
> 
> That's not the kind of example I was thinking if.  Do you have a real
> example, maybe?

Try writing a macro that emits a defstruct, then a function that uses
cl-typep for that struct, all wrapped in the same toplevel progn.

>> Some of the iface stuff I was working on used this functionality.
> 
>> The comments in bytecomp.el suggest that EIEIO has similar stuff.
> 
> No, that comment is about eieio.el using eval-and-compile over large
> swaths of code, which is very unusual, so I made eval-and-compile behave
> more like the usual top-level (before that eval-and-compile expanded
> all its macros in a single pass).

Yes, eieio uses eval-and-compile, but there's no reason the same
toplevel semantics shouldn't apply to regular progn.

>> In any case, it's a reasonable thing to want to do, so we should
>> support it.
> 
> I'm not sure I want to impose myself this level of detail.
> Especially since it'll also have to be ported to the eager
> macro-expansion code.

Other lisps provide the same functionality that my change does, and for
good reason. It's a simple, useful concept: macros can only generate one
form, so if they generate a progn, we treat each form in the progn as a
toplevel form. Not supporting this mode of operation makes elisp much
less useful.

The reason we have automated tests is to make sure we can maintain this
"level of detail". That it's not immediately useful to you isn't a
reason not to include it. I can't believe this issue is even
contentious: the current behavior is a clear bug.

> And OTOH your macro could expand calls to `abc' "manually" in the code
> it returns, and hence avoid this need.

How? By locally defining those macros in a temporary macrolet (which
we'd macroexpand-all?) in addition to emiting defmacros? What if the
macro generation is implicit, as it is with defstruct, so that the
top-level form doesn't even realize it has to employ this awful hack?

The need for this ridiculous and needless hack can be avoided if we just
have sane toplevel macro expansion semantics. Forcing people to rely on
tricks like what you propose instead of providing sane macro expansion
semantics will waste a lot of people's time.

signature.asc
Description: OpenPGP digital signature