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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>>> Correctly treat progn contents as toplevel forms when byte compiling
>> Your commit messages should be copies of the ChangeLog entry.
>> Could you describe the case(s) that this fixes?
> See the testcases. Generally speaking, this change fixes situations
> where the byte-compiler miscompiles code that contains (or generates)
> top-level progns that define macros, then use them.

Can you show an example of a macro that does that?

>>> +  ;; Macroexpand (not macroexpand-all!)
>> That could be a problem.
> Why? We macroexpand-all forms later when we actually compile or eval them.

Not sure why, exactly.  It just feels like it could be a problem.
Usually, we assume it's safe to use macroexpand-all, and it's not 100%
crystal clear why we could be sure that macroexpand-all won't be used.

> Unless there's a good reason to depart from CL, we should follow CL's
> approach to things. CL in a good sane default, and in this case, CL
> specifies exactly the right behavior.

Yes.  But Elisp's design constraints, especially w.r.t macro expansion,
are slightly different, partly for historical reasons, partly for
technical reasons.  It might not be relevant here, but I just want to
make double sure.


        Stefan