unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
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?

  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

  List information: https://www.gnu.org/software/emacs/

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