GNU bug report logs -
#52147
Eager macro-expansion is not performed in `eval-and-compile' functions
Previous Next
To reply to this bug, email your comments to 52147 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52147
; Package
emacs
.
(Sat, 27 Nov 2021 19:38:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Paul Pogonyshev <pogonyshev <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 27 Nov 2021 19:38:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Simple code to demonstrate this:
;; -*- lexical-binding: t -*-
(defmacro my-macro (x)
`,x)
(eval-and-compile
(defun my-func-eac (what)
(my-macro what)))
(defun my-func-normal (what)
(my-macro what))
(print (symbol-function 'my-func-eac))
(print (symbol-function 'my-func-normal))
`eval-and-compile' is advertised in Elisp manual to make byte-compilation
of certain macros without prior loading possible. Looks strange that at the
same time it can worsen performance of non-byte-compiled code.
Paul
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52147
; Package
emacs
.
(Sun, 28 Nov 2021 10:31:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 52147 <at> debbugs.gnu.org (full text, mbox):
Hello Paul,
> (eval-and-compile
> (defun my-func-eac (what)
> (my-macro what)))
>
> (defun my-func-normal (what)
> (my-macro what))
>
> (print (symbol-function 'my-func-eac))
> (print (symbol-function 'my-func-normal))
>
> `eval-and-compile' is advertised in Elisp manual to make
> byte-compilation of certain macros without prior loading
> possible. Looks strange that at the same time it can worsen
> performance of non-byte-compiled code.
Is the issue you want to draw attention to that an interpreted
`eval-and-compile' form doesn't macroexpand its body?
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52147
; Package
emacs
.
(Sun, 28 Nov 2021 21:55:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 52147 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
That's what the subject says. I know that it works regardless, but the
performance suffers, especially if the used macros are complex.
Paul
On Sun, 28 Nov 2021 at 11:30, Michael Heerdegen <michael_heerdegen <at> web.de>
wrote:
> Hello Paul,
>
> > (eval-and-compile
> > (defun my-func-eac (what)
> > (my-macro what)))
> >
> > (defun my-func-normal (what)
> > (my-macro what))
> >
> > (print (symbol-function 'my-func-eac))
> > (print (symbol-function 'my-func-normal))
> >
> > `eval-and-compile' is advertised in Elisp manual to make
> > byte-compilation of certain macros without prior loading
> > possible. Looks strange that at the same time it can worsen
> > performance of non-byte-compiled code.
>
> Is the issue you want to draw attention to that an interpreted
> `eval-and-compile' form doesn't macroexpand its body?
>
> Michael.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52147
; Package
emacs
.
(Mon, 29 Nov 2021 15:46:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 52147 <at> debbugs.gnu.org (full text, mbox):
Paul Pogonyshev <pogonyshev <at> gmail.com> writes:
> Is the issue you want to draw attention to that an interpreted
> `eval-and-compile' form doesn't macroexpand its body?
> That's what the subject says.
Well, not exactly -- it doesn't say anything about the code being
interpreted.
> I know that it works regardless, but the
> performance suffers, especially if the used macros are complex.
We usually don't stress a lot about the performance of interpreted
(i.e., uncompiled) code. Does this have a performance impact on
byte-compiled code?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 29 Nov 2021 15:46:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52147
; Package
emacs
.
(Mon, 29 Nov 2021 19:16:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 52147 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> We usually don't stress a lot about the performance of interpreted
> (i.e., uncompiled) code.
Well we do, a bit,
(info "(elisp) How Programs Do Loading")
says that loading a file performs eager macro expansion and that does
speed up the resulting code. `eval', `eval-when-compile' and
`eval-and-compile' don't perform eager macro expansion. I don't know to
what degree this is on purpose. But if a macro is defined later in the
file or in another file that has not yet been loaded this may not be
possible anyway.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52147
; Package
emacs
.
(Sat, 15 Jan 2022 13:11:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 52147 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> Well we do, a bit,
>
> (info "(elisp) How Programs Do Loading")
>
> says that loading a file performs eager macro expansion and that does
> speed up the resulting code. `eval', `eval-when-compile' and
> `eval-and-compile' don't perform eager macro expansion. I don't know to
> what degree this is on purpose. But if a macro is defined later in the
> file or in another file that has not yet been loaded this may not be
> possible anyway.
It sounds to me like things are basically working as designed.
Perhaps Stefan has some comments; added to the CCs.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52147
; Package
emacs
.
(Sat, 15 Jan 2022 15:10:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 52147 <at> debbugs.gnu.org (full text, mbox):
>>> We usually don't stress a lot about the performance of interpreted
>>> (i.e., uncompiled) code.
Indeed.
>> Well we do, a bit,
>>
>> (info "(elisp) How Programs Do Loading")
>>
>> says that loading a file performs eager macro expansion and that does
>> speed up the resulting code. `eval', `eval-when-compile' and
>> `eval-and-compile' don't perform eager macro expansion. I don't know to
>> what degree this is on purpose. But if a macro is defined later in the
>> file or in another file that has not yet been loaded this may not be
>> possible anyway.
>
> It sounds to me like things are basically working as designed.
>
> Perhaps Stefan has some comments; added to the CCs.
AFAIK the exact time of macro expansion is left underspecified
on purpose. Whether eager-macroexpansion is used or not should be an
implementation detail. A piece of code which relies on macro-expansion
being done lazily is a bug, AFAIC. Usually those bugs become apparent
when byte-compiling the file (where macro-expansion is necessarily
eager), except for those cases that occur during bootstrap.
Both `eval-when-compile` and `eval-and-compile` currently defer to
`eval`, but they should arguably do the macro-expansion eagerly, indeed.
`eval` currently doesn't use eager macro-expansion because I haven't
done the work needed to check/ensure that the resulting potential
slowdown is negligible. But I think `eval` should also eagerly
macro-expand its argument.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52147
; Package
emacs
.
(Thu, 20 Jan 2022 09:51:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 52147 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> Both `eval-when-compile` and `eval-and-compile` currently defer to
> `eval`, but they should arguably do the macro-expansion eagerly, indeed.
OK; I'll leave this bug report open as a wishlist item.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Severity set to 'wishlist' from 'normal'
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 20 Jan 2022 09:52:01 GMT)
Full text and
rfc822 format available.
Removed tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 20 Jan 2022 09:52:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 145 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.