unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Adam Porter <adam@alphapapa.net>
Cc: emacs-devel@gnu.org
Subject: Re: Expansion of macros at compile time in eval-and-compile bodies
Date: Tue, 07 Apr 2020 11:26:24 -0400	[thread overview]
Message-ID: <jwvblo38h8d.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87a73nid16.fsf_-_@alphapapa.net> (Adam Porter's message of "Tue,  07 Apr 2020 09:30:29 -0500")

>   In order for compilation of macro calls to work, the macros must
>   already be defined in Lisp when the calls to them are compiled.  The
>   compiler has a special feature to help you do this: if a file being
>   compiled contains a ‘defmacro’ form, the macro is defined temporarily
>   for the rest of the compilation of that file.
>
> That would seem to imply that the error shouldn't happen, because the
> macro is defined in the same file before it is called.

The "temporarily" part is too vague to precisely describe what happens.
What really happens is that the compiler remembers the macros it has
compiled in the current file so that when it seen a call to them it can
expand it.  But it's not defined globally, so any macro-expansion that
is not performed directly by the byte-compiler doesn't actually see it.

Whether the provided example should or should not work depends on how we
think macro-expansion within `eval-and-compile` should behave.
Maybe Common-Lisp's `eval-when` specifies this more precisely, and that
could be a motivation to make the behavior of `eval-and-compile` more
precise as well (and that might also motivate changing its behavior in
corner cases like the above, tho not necessarily).

>   You can get a similar result by putting BODY in a separate file and
>   referring to that file with ‘require’.

Clearly, if you put BODY into a separate file and `require` it, BODY
won't be macro-expanded directly by the compiler that compiles the
`require` (it should ideally be macro-expanded in a separate compilation
phase before compiling the file that `require`s).

> Does that mean that the body of an eval-and-compile form is evaluated in
> a different environment than the one defined by the file containing the
> eval-and-compile form?

Pretty much.  tho I don't think any code relies on that detail.

> If so, putting the macro definition in an
> eval-and-compile form wouldn't seem to imply that a macro defined in it
> would be available in subsequent eval-and-compile forms.

Yes, it does, because the two forms contained within those two
`eval-and-compile` will be executed in sequence within the same Emacs
session, so the first will globally define the macro, which will thus be
defined when macro-expanding the second.

> Maybe I'm just missing something obvious, but I wonder if the manual is
> missing an explanation of this finer point.

A lof of such finer points are purposefully not documented because the
exact behavior will depend on circumstances (we want to leave some
freedom to the implementation).

IOW, the user of those macros should avoid relying on those
finer points.

>> Changing topic I have no idea why this instead go through.  To me looks
>> like a bug, isn't?
>>
>> #+BEGIN_SRC elisp
>> ;;; bufler.el  -*- lexical-binding: t; -*-
>>
>> (defmacro bufler-defauto-group ())
>>
>>  (eval-and-compile
>>    (bufler-defauto-group))
>> #+BEGIN_END

I think it's a side-effect of `byte-compile-recurse-toplevel`, which
tries to implement the behavior described in CLHS section
3.2.3.1, "Processing of Top Level Forms".

Maybe this could be considered as a bug, but we could also just say that
it's one of those finer points on which one shouldn't rely.


        Stefan




      reply	other threads:[~2020-04-07 15:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-05 14:01 [native-comp] Small, new bug with macros? Adam Porter
2020-04-05 14:12 ` Andrea Corallo
2020-04-05 14:41   ` Adam Porter
2020-04-06 20:45     ` Andrea Corallo
2020-04-07 14:30       ` Expansion of macros at compile time in eval-and-compile bodies (was: Re: [native-comp] Small, new bug with macros?) Adam Porter
2020-04-07 15:26         ` Stefan Monnier [this message]

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=jwvblo38h8d.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=adam@alphapapa.net \
    --cc=emacs-devel@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 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).