GNU bug report logs - #60450
30.0.50; Strange behavior of compiler macros in *scratch*

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60450 in the body.
You can then email your comments to 60450 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Strange behavior of compiler macros in *scratch*
Date: Sat, 31 Dec 2022 14:22:31 +0100

The doc string of cl-define-compiler-macro says

  "This is like ‘defmacro’, but macro expansion occurs only if the call 
to FUNC is compiled (i.e., not interpreted)."

Evaluate the following compiler macro and function in *scratch*:

(cl-define-compiler-macro foo ()
  1)

(defun foo ()
  2)

Then:

(eval '(foo))
  => 2

(foo)C-j
  => 1

C-j is bound to eval-print-last-sexp, which I wouldn't expect to compile 
anything, and its doc string doesn't mention anything AFAICS.  Not sure 
if that's a bug in the code or something missing in the docs.

Message #8 received at 60450 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 60450 <at> debbugs.gnu.org
Subject: Re: bug#60450: 30.0.50; Strange behavior of compiler macros in
 *scratch*
Date: Sat, 31 Dec 2022 15:42:34 +0100

On Dez 31 2022, Gerd Möllmann wrote:

> C-j is bound to eval-print-last-sexp, which I wouldn't expect to compile
> anything, and its doc string doesn't mention anything AFAICS.  Not sure if
> that's a bug in the code or something missing in the docs.

eval-print-last-sexp uses macroexpand-all.

(macroexpand-all '(foo)) => 1

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #11 received at 60450 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 60450 <at> debbugs.gnu.org
Subject: Re: bug#60450: 30.0.50; Strange behavior of compiler macros in
 *scratch*
Date: Sun, 1 Jan 2023 07:34:31 +0100

On 31.12.22 15:42, Andreas Schwab wrote:
> On Dez 31 2022, Gerd Möllmann wrote:
> 
>> C-j is bound to eval-print-last-sexp, which I wouldn't expect to compile
>> anything, and its doc string doesn't mention anything AFAICS.  Not sure if
>> that's a bug in the code or something missing in the docs.
> 
> eval-print-last-sexp uses macroexpand-all.
> 
> (macroexpand-all '(foo)) => 1
> 

Right.  And macroexpand-all seems to be closely tied to the compiler, or 
the other way round, depending on one's perspective.  I personally find 
that behavior a bit surprising, but that's just me.  If someone wants to 
close this bug, please do.

Message #14 received at 60450 <at> debbugs.gnu.org (full text, mbox):

From: Lynn Winebarger <owinebar <at> gmail.com>
To: 60450 <at> debbugs.gnu.org
Subject: Re: bug#60450: 30.0.50;
 Strange behavior of compiler macros in *scratch*
Date: Sun, 7 May 2023 21:59:51 -0400

I was going to open a feature request bug for a function to
specifically expand compiler-macros, but if the behavior reported here
is intended, then I don't really need to.

However, if this is the intended behavior of macroexpand-all, it is
inconsistent with the documentation, which says:

     ‘macroexpand-all’ expands macros like ‘macroexpand’, but will look
     for and expand all macros in FORM, not just at the top-level.  If
     no macros are expanded, the return value is ‘eq’ to FORM.

But macroexpand is defined in C source code, and definitely *only*
expands function symbols whose value has a car of 'macro.

Could someone determine if this is a bug in macroexpand-all (e.g. it
should be checking whether it is being called while byte-compiling),
or just a documentation bug?

Thanks,
Lynn

Message #17 received at 60450 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lynn Winebarger <owinebar <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 60450 <at> debbugs.gnu.org
Subject: Re: bug#60450: 30.0.50;
 Strange behavior of compiler macros in *scratch*
Date: Mon, 08 May 2023 14:29:15 +0300

> From: Lynn Winebarger <owinebar <at> gmail.com>
> Date: Sun, 7 May 2023 21:59:51 -0400
> 
> I was going to open a feature request bug for a function to
> specifically expand compiler-macros, but if the behavior reported here
> is intended, then I don't really need to.
> 
> However, if this is the intended behavior of macroexpand-all, it is
> inconsistent with the documentation, which says:
> 
>      ‘macroexpand-all’ expands macros like ‘macroexpand’, but will look
>      for and expand all macros in FORM, not just at the top-level.  If
>      no macros are expanded, the return value is ‘eq’ to FORM.
> 
> But macroexpand is defined in C source code, and definitely *only*
> expands function symbols whose value has a car of 'macro.
> 
> Could someone determine if this is a bug in macroexpand-all (e.g. it
> should be checking whether it is being called while byte-compiling),
> or just a documentation bug?

Adding Stefan.

Message #20 received at 60450 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 60450 <at> debbugs.gnu.org
Subject: Re: bug#60450: 30.0.50; Strange behavior of compiler macros in
 *scratch*
Date: Mon, 08 May 2023 08:25:41 -0400

> The doc string of cl-define-compiler-macro says
>   "This is like ‘defmacro’, but macro expansion occurs only if the call to
>  FUNC is compiled (i.e., not interpreted)."

`cl-define-compiler-macro` is built on top of the "new" ELisp compiler
macro feature.  I think that feature is documented vaguely (poorly?)
enough that it does allow expansion (or not) for interpreted code.

> C-j is bound to eval-print-last-sexp, which I wouldn't expect to compile
> anything, and its doc string doesn't mention anything AFAICS.  Not sure if
> that's a bug in the code or something missing in the docs.

Trying to distinguish those calls to `macroexpand-all` which come from
the compiler from those that come from elsewhere doesn't seem worth the
trouble, so I'd rather consider it as a doc bug.

The doc should also make it clear that contrary to `defmacro` there is
no guarantee that it will be called (nor *when* it's called).


        Stefan

Message #23 received at 60450 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 60450 <at> debbugs.gnu.org
Subject: Re: bug#60450: 30.0.50; Strange behavior of compiler macros in
 *scratch*
Date: Sat, 18 May 2024 08:33:23 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> The doc string of cl-define-compiler-macro says
>>   "This is like ‘defmacro’, but macro expansion occurs only if the call to
>>  FUNC is compiled (i.e., not interpreted)."
>
> `cl-define-compiler-macro` is built on top of the "new" ELisp compiler
> macro feature.  I think that feature is documented vaguely (poorly?)
> enough that it does allow expansion (or not) for interpreted code.
>
>> C-j is bound to eval-print-last-sexp, which I wouldn't expect to compile
>> anything, and its doc string doesn't mention anything AFAICS.  Not sure if
>> that's a bug in the code or something missing in the docs.
>
> Trying to distinguish those calls to `macroexpand-all` which come from
> the compiler from those that come from elsewhere doesn't seem worth the
> trouble, so I'd rather consider it as a doc bug.
>
> The doc should also make it clear that contrary to `defmacro` there is
> no guarantee that it will be called (nor *when* it's called).

I don't think that this will be changed, so I'm closing this bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.