bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*

bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*

[Gerd Möllmann]

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.

bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*

[Gerd Möllmann]

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.

bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*

[Lynn Winebarger]

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

bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*

[Eli Zaretskii]

> From: Lynn Winebarger <owinebar@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.

bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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

bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*

[Gerd Möllmann]

Stefan Monnier <monnier@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.