unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*
@ 2022-12-31 13:22 Gerd Möllmann
  2022-12-31 14:42 ` Andreas Schwab
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Gerd Möllmann @ 2022-12-31 13:22 UTC (permalink / raw)
  To: 60450

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.







^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*
  2022-12-31 13:22 bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch* Gerd Möllmann
@ 2022-12-31 14:42 ` Andreas Schwab
  2023-01-01  6:34   ` Gerd Möllmann
  2023-05-08  1:59 ` Lynn Winebarger
  2023-05-08 12:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2 siblings, 1 reply; 7+ messages in thread
From: Andreas Schwab @ 2022-12-31 14:42 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: 60450

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."





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*
  2022-12-31 14:42 ` Andreas Schwab
@ 2023-01-01  6:34   ` Gerd Möllmann
  0 siblings, 0 replies; 7+ messages in thread
From: Gerd Möllmann @ 2023-01-01  6:34 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: 60450

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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*
  2022-12-31 13:22 bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch* Gerd Möllmann
  2022-12-31 14:42 ` Andreas Schwab
@ 2023-05-08  1:59 ` Lynn Winebarger
  2023-05-08 11:29   ` Eli Zaretskii
  2023-05-08 12:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2 siblings, 1 reply; 7+ messages in thread
From: Lynn Winebarger @ 2023-05-08  1:59 UTC (permalink / raw)
  To: 60450

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*
  2023-05-08  1:59 ` Lynn Winebarger
@ 2023-05-08 11:29   ` Eli Zaretskii
  0 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2023-05-08 11:29 UTC (permalink / raw)
  To: Lynn Winebarger, Stefan Monnier; +Cc: 60450

> 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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*
  2022-12-31 13:22 bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch* Gerd Möllmann
  2022-12-31 14:42 ` Andreas Schwab
  2023-05-08  1:59 ` Lynn Winebarger
@ 2023-05-08 12:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-05-18  6:33   ` Gerd Möllmann
  2 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-05-08 12:25 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: 60450

> 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






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch*
  2023-05-08 12:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-05-18  6:33   ` Gerd Möllmann
  0 siblings, 0 replies; 7+ messages in thread
From: Gerd Möllmann @ 2024-05-18  6:33 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 60450

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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2024-05-18  6:33 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-12-31 13:22 bug#60450: 30.0.50; Strange behavior of compiler macros in *scratch* Gerd Möllmann
2022-12-31 14:42 ` Andreas Schwab
2023-01-01  6:34   ` Gerd Möllmann
2023-05-08  1:59 ` Lynn Winebarger
2023-05-08 11:29   ` Eli Zaretskii
2023-05-08 12:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-18  6:33   ` Gerd Möllmann

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).