From: Drew Adams <drew.adams@oracle.com>
To: Heime <heimeborgia@protonmail.com>,
Heime via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org>
Subject: RE: [External] : macros and macroexpand
Date: Mon, 7 Aug 2023 14:28:42 +0000 [thread overview]
Message-ID: <SJ0PR10MB5488AB1781ECE352186A61C0F30CA@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <vK2GWkxpqGqPlc3-e1C8U9jFMzj_D3_fTnTeTrGfAa67tCiSJv-_LnOzg647JK0IkWzVnv7E7BRqAE5-Eb_cQ1wyZ_SityPYX6JjJwxHolY=@protonmail.com>
> I have made a macro and know that they are supposed to return
> expanded code for use. Still I cannot understand the need to
> call "macroexpand". Should't the macro already perform the
> expansion ?
This was amply explained in the answers
to your question when you posted in to
emacs.SE:
https://emacs.stackexchange.com/q/78347
____
In sum (repeating), the Lisp interpreter
evaluates sexps, including macro calls.
When it evaluates a macro call, it first
expands it according to the macro body
(which is effectively a sexp-to-sexp
pure function, regardless of how it's
implemented). This is _rewriting_ code.
After expanding the macro call, i.e.,
replacing it with a different sexp, the
interpreter evaluates that sexp (which
returns the result of that evaluation).
____
The byte-compiler just _expands_ macro
calls, then byte-compiles the expansions.
That is, byte-compilation doesn't also
_evaluate_ the result of macro expansion.
Evaluation is done when the byte-compiled
code is evaluated/interpreted.
____
A macro call is a particular kind of
sexp, of course: it's a list with a
symbol as car, that is, it looks to Lisp
like a function call. (There are also
symbol macros, which act similarly, but
on symbols not lists.)
____
You've been told all of this a few times
now. If there's some particular part of
it that you don't understand then you
should ask only about that part. Instead,
your MO is to broadcast the same question
multiple times to multiple places.
I can understand your wanting to get
different opinions, but your understanding
(which does progress) isn't reflected in
narrower questions. Why is that?
next prev parent reply other threads:[~2023-08-07 14:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-07 11:03 macros and macroexpand Heime
2023-08-07 11:46 ` Yuri Khan
2023-08-07 12:43 ` Heime
2023-08-07 14:22 ` Philip Kaludercic
2023-08-07 18:06 ` Heime
2023-08-07 20:08 ` Philip Kaludercic
2023-08-07 20:56 ` Heime
2023-08-07 22:10 ` Emanuel Berg
2023-08-08 20:35 ` Heime
2023-08-08 5:57 ` Philip Kaludercic
2023-08-07 14:28 ` Drew Adams [this message]
2023-08-07 18:22 ` [External] : " Heime
2023-08-07 19:04 ` Emanuel Berg
2023-08-07 18:59 ` Emanuel Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR10MB5488AB1781ECE352186A61C0F30CA@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=heimeborgia@protonmail.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.