From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Expansion of macros at compile time in eval-and-compile bodies Date: Tue, 07 Apr 2020 11:26:24 -0400 Message-ID: References: <87h7xyhu5f.fsf@alphapapa.net> <87a73nid16.fsf_-_@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="59616"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Adam Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 07 17:27:06 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jLq80-000FN8-Lq for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Apr 2020 17:27:04 +0200 Original-Received: from localhost ([::1]:49276 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLq7z-0005C3-PE for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Apr 2020 11:27:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39457) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLq7T-0004kv-28 for emacs-devel@gnu.org; Tue, 07 Apr 2020 11:26:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jLq7R-0002dH-AY for emacs-devel@gnu.org; Tue, 07 Apr 2020 11:26:30 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63853) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jLq7R-0002cB-3O for emacs-devel@gnu.org; Tue, 07 Apr 2020 11:26:29 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2EA7E44FDCC; Tue, 7 Apr 2020 11:26:28 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id AAEF044FDC6; Tue, 7 Apr 2020 11:26:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1586273186; bh=wq//+CElhz9smH4kaUabBJ/BWM4v61fbWKJcQkyjCAA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=lR1/lPhj1No6xp9WLH2BxqCSXJ/SNAW/hV2ECQ79/SEP9+zP5s2DEsDYqt4kBtaMD Vh50GVYGpI3cJZ0G9YxMBa0yZUhSddks8xke/ihSM5Zyjec+b257zvOwAdA5h6MbX9 jwrWXOFi1N/8w24j0tD4yOMu4yq/VofUUvfB/hkFIoI5kYXJzkDEg3eT3JFgPbj8ud 9Ni2/fKF0eGXFqrNXsOp6Zqt01dTtMqGSqtp2s21OC+WQ1nv0Bk5A4QRmf/zhlGgJ7 EwE2S8RIu/fM5DJGBKsJSmYZoCChkNCTrRR2sEiuJtnAUsu/k96vH21sjdZ1cTngVc TLfEHDQwiIuDA== Original-Received: from alfajor (unknown [104.247.241.114]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 254F91204BA; Tue, 7 Apr 2020 11:26:26 -0400 (EDT) In-Reply-To: <87a73nid16.fsf_-_@alphapapa.net> (Adam Porter's message of "Tue, 07 Apr 2020 09:30:29 -0500") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246612 Archived-At: > 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 =E2=80=98defmacro=E2=80=99 form, the macro is defin= ed 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 =E2=80=98require=E2=80=99. 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