From unknown Sat Aug 09 15:55:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53526: 29.0.50; macroexp-warn-and-return API change Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: acm@muc.de, bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Jan 2022 16:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 53526 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 53526@debbugs.gnu.org Cc: Alan Mackenzie X-Debbugs-Original-To: bug-gnu-emacs@gnu.org X-Debbugs-Original-Xcc: Alan Mackenzie Received: via spool by submit@debbugs.gnu.org id=B.16431298124820 (code B ref -1); Tue, 25 Jan 2022 16:57:01 +0000 Received: (at submit) by debbugs.gnu.org; 25 Jan 2022 16:56:52 +0000 Received: from localhost ([127.0.0.1]:49926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCP7k-0001Fg-62 for submit@debbugs.gnu.org; Tue, 25 Jan 2022 11:56:52 -0500 Received: from lists.gnu.org ([209.51.188.17]:60752) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCP7i-0001FX-8D for submit@debbugs.gnu.org; Tue, 25 Jan 2022 11:56:50 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57850) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCP7h-0002mZ-W3 for bug-gnu-emacs@gnu.org; Tue, 25 Jan 2022 11:56:50 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:44800) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCP7U-0002Qr-QI for bug-gnu-emacs@gnu.org; Tue, 25 Jan 2022 11:56:49 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A3F48805F9 for ; Tue, 25 Jan 2022 11:56:34 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 61A54805CC for ; Tue, 25 Jan 2022 11:56:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1643129793; bh=eETqpFXjSJWnAfWZxzJ+juagNM8adfq93bDbNOub4EE=; h=From:To:Subject:Date:From; b=pht9BNuVBdjjMVmv9yyzKxE3w0FhkzCEeA8yyRrnvE3zFp3V4GqVulxHyyMtb/bER jz80XwUzBVheuFEk2LBh4lGkdjuvNRdEaak/ZVnlf3ErJkI42On/AIy33m26PbJOqr Pn87zc2RD+xXFRD3lcbciXkzsTIHsgoj2t170wWlP1MiOCjfL9dTLSf1pQ0LFB8lDz UaXZVTA3uWNVy2Naltu42NSuqMoWHNNJGOqRFawbGydclm+1OXSJnTgrCd0/a6R7E8 OYlzOETFyrEIKJxM1jzh1//+dqhPZ+oDFU00vaonXjWm7GyCGyOk4zacPGxQLwqb3t 31ZPgVyMl1q0Q== Received: from ceviche (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3EF1F120434 for ; Tue, 25 Jan 2022 11:56:33 -0500 (EST) From: Stefan Monnier Date: Tue, 25 Jan 2022 11:56:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.139 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Package: Emacs Version: 29.0.50 The following change in `macroexp.el` on `master` is not backward compatible with the Emacs-28 API: -(defun macroexp-warn-and-return (msg form &optional category compile-only) +(defun macroexp-warn-and-return (arg msg form &optional category compile-only) I suspect that the `arg` should be added at the end instead. While I'm here I also noticed that `byte-compile-form-stack` is a poor name for a variable declared in `macroexp.el`. It should either be renamed to use the `macroexp-` prefix, or moved to `bytecomp.el` (and it probably should have a double-hyphen, since I think it's not meant to be used by anyone but us). Stefan From unknown Sat Aug 09 15:55:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53526: 29.0.50; macroexp-warn-and-return API change Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Jan 2022 18:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53526 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 53526@debbugs.gnu.org Received: via spool by 53526-submit@debbugs.gnu.org id=B53526.164313462721614 (code B ref 53526); Tue, 25 Jan 2022 18:18:02 +0000 Received: (at 53526) by debbugs.gnu.org; 25 Jan 2022 18:17:07 +0000 Received: from localhost ([127.0.0.1]:50030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCQNP-0005cY-DB for submit@debbugs.gnu.org; Tue, 25 Jan 2022 13:17:07 -0500 Received: from colin.muc.de ([193.149.48.1]:23147 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nCQNM-0005bw-8q for 53526@debbugs.gnu.org; Tue, 25 Jan 2022 13:17:06 -0500 Received: (qmail 83171 invoked by uid 3782); 25 Jan 2022 18:16:57 -0000 Received: from acm.muc.de (p4fe1523e.dip0.t-ipconnect.de [79.225.82.62]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 25 Jan 2022 19:16:57 +0100 Received: (qmail 4779 invoked by uid 1000); 25 Jan 2022 18:16:56 -0000 Date: Tue, 25 Jan 2022 18:16:56 +0000 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Tue, Jan 25, 2022 at 11:56:22 -0500, Stefan Monnier wrote: > Package: Emacs > Version: 29.0.50 > The following change in `macroexp.el` on `master` is not backward > compatible with the Emacs-28 API: > -(defun macroexp-warn-and-return (msg form &optional category compile-only) > +(defun macroexp-warn-and-return (arg msg form &optional category compile-only) No, it isn't. All the uses of the function are in lisp/emacs-lisp, and I understood the function to be an internal one. > I suspect that the `arg` should be added at the end instead. The other functions (like byte-compile-warn-x) which have acquired this extra argument need to have it at the start, since there are an indeterminate number of &rest args going into a `format'. So it seemed better just to do the same with this function, to preserve a sort of compatibility. > While I'm here I also noticed that `byte-compile-form-stack` is a poor > name for a variable declared in `macroexp.el`. It's an integral part of bytecomp.el. It got moved to macroexp.el because it is used (twice) there, and that file is loaded into bootstrap emacs before bytecomp.el. There is precedent for this "mis"naming, namely byte-compile-bound-variables. > It should either be renamed to use the `macroexp-` prefix, or moved to > `bytecomp.el` (and it probably should have a double-hyphen, since I > think it's not meant to be used by anyone but us). It started off life with a double hyphen in bytecomp.el. But when it started getting used in macroexp.el (during the expansion of a macro) it lost the extra hyphen and got moved there. It's no big deal, I think, just that there's no completely neat way of doing this, so the compromise actually used is pretty arbitrary. If the variable were in bytecomp.el, we'd probably need a boundp call in the two places we use it in macroexp.el. Whilst on the topic of macroexp-warn-and-return (and macroexp--wrap-warn), I have to admit having difficulty understanding these functions, both how they work and what they're for. My impression up till a couple of days ago was that they were ways of coping with the old warning position mechanism, and were intended to compensate for its deficiencies. Now, I'm much less sure. Was I indeed mistaken? If I was, what then is the purpose of these functions, which defer warning messages in some fashion? If I was right, it would be a good thing to dismantle them, since they are complicated and difficult, and no longer needed. As I said, I don't really understand them. Thanks! > Stefan -- Alan Mackenzie (Nuremberg, Germany). From unknown Sat Aug 09 15:55:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53526: 29.0.50; macroexp-warn-and-return API change Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Jan 2022 19:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53526 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 53526@debbugs.gnu.org Received: via spool by 53526-submit@debbugs.gnu.org id=B53526.16431378393355 (code B ref 53526); Tue, 25 Jan 2022 19:11:02 +0000 Received: (at 53526) by debbugs.gnu.org; 25 Jan 2022 19:10:39 +0000 Received: from localhost ([127.0.0.1]:50112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCRDD-0000s2-0l for submit@debbugs.gnu.org; Tue, 25 Jan 2022 14:10:39 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:51362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCRD7-0000rj-GM for 53526@debbugs.gnu.org; Tue, 25 Jan 2022 14:10:37 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6DEC84428C6; Tue, 25 Jan 2022 14:10:27 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7A9E74428C0; Tue, 25 Jan 2022 14:10:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1643137825; bh=oL91isvRWsT3BaZwCeQPj7sI0QI8g4SPhOSh3hNY/pA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=o9XpKIxhzIfjC2Fq7YG5e2XdnPD0oAoGDYcx7gNIY677TsNS1BuPie7nIgs4pOLLs Ar9GHbURCb9WD2Knh7iHSqAblYupgSL3kcvg6n3GCbldbvQO7/lhTYvDWcNW3dI9Gm Eo95H47vg9wes0w/UfyFsEZs59C0cu3pQosxLxVD5vN1Jrz6BsoIAehkE6iJWyan5y dkEuSWfrhsGnf1FAawalknCzJPHT99AOY8glgSksVZwumlgMFITwhZRYRuowqYmXgm IzJTQiaFUfLVXAujxpsY256Jiee3AX+1hCCKKwSuJs10qsUq0MlZAeH8PHnS0hDB10 yTtRrX/ncfDKw== Received: from pastel (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3860312098D; Tue, 25 Jan 2022 14:10:25 -0500 (EST) From: Stefan Monnier Message-ID: References: Date: Tue, 25 Jan 2022 14:10:12 -0500 In-Reply-To: (Alan Mackenzie's message of "Tue, 25 Jan 2022 18:16:56 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.492 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> -(defun macroexp-warn-and-return (msg form &optional category compile-only) >> +(defun macroexp-warn-and-return (arg msg form &optional category compile-only) > No, it isn't. All the uses of the function are in lisp/emacs-lisp, and > I understood the function to be an internal one. No, its name was changed from "macroexp--" to "macroexp-" in Emacs-28, specifically to make available for third party packages. It was announced in etc/NEWS, for example. While `bindat.el` lives in `lisp/emacs-lisp`, it's an example of a non-core package that benefits from it. >> I suspect that the `arg` should be added at the end instead. > The other functions (like byte-compile-warn-x) which have acquired this > extra argument need to have it at the start, since there are an > indeterminate number of &rest args going into a `format'. So it seemed > better just to do the same with this function, to preserve a sort of > compatibility. While I can see the value of this aesthetic argument, I think breaking backward compatibility was a published API is a more serious problem. On the upside, moving it to the end will make it optional, which is good since in many cases we can use the `form` argument instead (which `byte-compile-warn-x` doesn't have). >> While I'm here I also noticed that `byte-compile-form-stack` is a poor >> name for a variable declared in `macroexp.el`. > > It's an integral part of bytecomp.el. It got moved to macroexp.el > because it is used (twice) there, and that file is loaded into bootstrap > emacs before bytecomp.el. > > There is precedent for this "mis"naming, namely > byte-compile-bound-variables. `byte-compile-bound-variables` is defined in `bytecomp.el`, not in `macroexp.el`. And indeed, `byte-compile-bound-variables` is only set/modified by the byte compiler, so it really belongs there. I can see that just moving the definition to bytecomp.el and using (defvar byte-compile-form-stack) in macroexp.el won't work because the `push` requires the var to have a value. Still, the current setup is really ugly: that var belongs in `bytecomp.el`. > It started off life with a double hyphen in bytecomp.el. But when it > started getting used in macroexp.el (during the expansion of a macro) it > lost the extra hyphen and got moved there. I'd put a double hyphen there simply because it's not something that we want to expose as an official API. Just because the bytecompiler's macroexpansion phase is implemented in a separate file doesn't justify making the var public. > It's no big deal, I think, just that there's no completely neat way of > doing this, so the compromise actually used is pretty arbitrary. > If the variable were in bytecomp.el, we'd probably need a boundp call > in the two places we use it in macroexp.el. It at least deserves a prominent comment explaining why it's there. > Whilst on the topic of macroexp-warn-and-return (and > macroexp--wrap-warn), I have to admit having difficulty understanding > these functions, both how they work and what they're for. > > My impression up till a couple of days ago was that they were ways of > coping with the old warning position mechanism, and were intended to > compensate for its deficiencies. The original motivation was indeed to improve the error messages by including more relevant line information. This part was made largely irrelevant with your patch. But it's still relevant because macros can use it without being tied to the byte-compiler. Also a nice side-effect is that the warnings are emitted (mostly) in the order they appear in the code, whereas otherwise we'd first have the warnings emitted during macroexpansion, then warnings emitted during the compilation. > Now, I'm much less sure. Was I indeed mistaken? If I was, what then is > the purpose of these functions, which defer warning messages in some > fashion? If I was right, it would be a good thing to dismantle them, > since they are complicated and difficult, and no longer needed. As I > said, I don't really understand them. I don't see what's difficult about it: it lets you attach a warning to a piece of code. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 28 21:31:02 2022 Received: (at control) by debbugs.gnu.org; 29 Jan 2022 02:31:02 +0000 Received: from localhost ([127.0.0.1]:60785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nDdW2-00036p-BQ for submit@debbugs.gnu.org; Fri, 28 Jan 2022 21:31:02 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59898) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nDdW0-00036K-04 for control@debbugs.gnu.org; Fri, 28 Jan 2022 21:31:00 -0500 Received: from [2001:470:142:3::e] (port=60250 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nDdVu-0007W7-N8 for control@debbugs.gnu.org; Fri, 28 Jan 2022 21:30:54 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1nDdVu-0002oj-IK for control@debbugs.gnu.org; Fri, 28 Jan 2022 21:30:54 -0500 Subject: control message for bug 53618 To: X-Mailer: mail (GNU Mailutils 3.4) Message-Id: From: Glenn Morris Date: Fri, 28 Jan 2022 21:30:54 -0500 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) merge 53526 53618 From unknown Sat Aug 09 15:55:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53526: 29.0.50; macroexp-warn-and-return API change Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Jan 2022 13:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53526 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 53526@debbugs.gnu.org Received: via spool by 53526-submit@debbugs.gnu.org id=B53526.164354965015562 (code B ref 53526); Sun, 30 Jan 2022 13:35:02 +0000 Received: (at 53526) by debbugs.gnu.org; 30 Jan 2022 13:34:10 +0000 Received: from localhost ([127.0.0.1]:35737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEALJ-00042v-Lo for submit@debbugs.gnu.org; Sun, 30 Jan 2022 08:34:10 -0500 Received: from colin.muc.de ([193.149.48.1]:43408 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nEALH-00042Q-OR for 53526@debbugs.gnu.org; Sun, 30 Jan 2022 08:34:08 -0500 Received: (qmail 84490 invoked by uid 3782); 30 Jan 2022 13:34:00 -0000 Received: from acm.muc.de (p2e5d54eb.dip0.t-ipconnect.de [46.93.84.235]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 30 Jan 2022 14:34:00 +0100 Received: (qmail 25242 invoked by uid 1000); 30 Jan 2022 13:34:00 -0000 Date: Sun, 30 Jan 2022 13:34:00 +0000 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Tue, Jan 25, 2022 at 14:10:12 -0500, Stefan Monnier wrote: > >> -(defun macroexp-warn-and-return (msg form &optional category compile-only) > >> +(defun macroexp-warn-and-return (arg msg form &optional category compile-only) > > No, it isn't. All the uses of the function are in lisp/emacs-lisp, and > > I understood the function to be an internal one. > No, its name was changed from "macroexp--" to "macroexp-" in Emacs-28, > specifically to make available for third party packages. It was > announced in etc/NEWS, for example. Are you aware of it being used anywhere else but lisp/emacs-lisp? > While `bindat.el` lives in `lisp/emacs-lisp`, it's an example of > a non-core package that benefits from it. > >> I suspect that the `arg` should be added at the end instead. > > The other functions (like byte-compile-warn-x) which have acquired this > > extra argument need to have it at the start, since there are an > > indeterminate number of &rest args going into a `format'. So it seemed > > better just to do the same with this function, to preserve a sort of > > compatibility. > While I can see the value of this aesthetic argument, I think breaking > backward compatibility was a published API is a more serious problem. Again, does anything else use it? > On the upside, moving it to the end will make it optional, which is good > since in many cases we can use the `form` argument instead (which > `byte-compile-warn-x` doesn't have). > >> While I'm here I also noticed that `byte-compile-form-stack` is a poor > >> name for a variable declared in `macroexp.el`. > > It's an integral part of bytecomp.el. It got moved to macroexp.el > > because it is used (twice) there, and that file is loaded into bootstrap > > emacs before bytecomp.el. > > There is precedent for this "mis"naming, namely > > byte-compile-bound-variables. > `byte-compile-bound-variables` is defined in `bytecomp.el`, not in `macroexp.el`. > And indeed, `byte-compile-bound-variables` is only set/modified by the > byte compiler, so it really belongs there. > I can see that just moving the definition to bytecomp.el and using > (defvar byte-compile-form-stack) in macroexp.el won't work because the > `push` requires the var to have a value. > Still, the current setup is really ugly: that var belongs in > `bytecomp.el`. Well, I suppose it could be defined in bytecomp.el and just declared in macroexp.el. It's not going to get used before it's been initialised in bytecomp.el. > > It started off life with a double hyphen in bytecomp.el. But when it > > started getting used in macroexp.el (during the expansion of a macro) it > > lost the extra hyphen and got moved there. > I'd put a double hyphen there simply because it's not something that we > want to expose as an official API. Just because the bytecompiler's > macroexpansion phase is implemented in a separate file doesn't justify > making the var public. OK, we can mange that. > > It's no big deal, I think, just that there's no completely neat way of > > doing this, so the compromise actually used is pretty arbitrary. > > If the variable were in bytecomp.el, we'd probably need a boundp call > > in the two places we use it in macroexp.el. > It at least deserves a prominent comment explaining why it's there. > > Whilst on the topic of macroexp-warn-and-return (and > > macroexp--wrap-warn), I have to admit having difficulty understanding > > these functions, both how they work and what they're for. > > My impression up till a couple of days ago was that they were ways of > > coping with the old warning position mechanism, and were intended to > > compensate for its deficiencies. > The original motivation was indeed to improve the error messages by > including more relevant line information. This part was made largely > irrelevant with your patch. > But it's still relevant because macros can use it without being tied to > the byte-compiler. Also a nice side-effect is that the warnings are > emitted (mostly) in the order they appear in the code, whereas otherwise > we'd first have the warnings emitted during macroexpansion, then > warnings emitted during the compilation. OK, thanks. > > Now, I'm much less sure. Was I indeed mistaken? If I was, what then is > > the purpose of these functions, which defer warning messages in some > > fashion? If I was right, it would be a good thing to dismantle them, > > since they are complicated and difficult, and no longer needed. As I > > said, I don't really understand them. > I don't see what's difficult about it: it lets you attach a warning to > a piece of code. There's a lot difficult about it. The doc string says, vaguely, "Return code equivalent to FORM labeled with warning MSG.". "Labeled" is not used like this anywhere else in Emacs. Nothing says what the nature of this "labelling" is, or what needs to be done to the resulting code to make it executable, when the "labelling" gets undone, or when the warning gets emitted. Nothing says what "equivalent" means here, either. In what sense is the new code "equivalent", and in what respects is it different? The source code is difficult to read, too. At least, I found it so, having spent several hours on it. macroexp--warn-wrap, an essential part of the mechanism, is entirely lacking any doc string or comment. It performs actions when it is called, and returns code which is going to get executed at some later stage. When? A comment explaining this would be exceptionally helpful. Nothing in the source code says what macroexp-warn-and-return is _for_. I suspect the difficulty in understanding this facility will have strongly dissuaded any external hackers from attempting to use it. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From unknown Sat Aug 09 15:55:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53526: 29.0.50; macroexp-warn-and-return API change Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Jan 2022 17:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53526 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 53526@debbugs.gnu.org Received: via spool by 53526-submit@debbugs.gnu.org id=B53526.164356211923198 (code B ref 53526); Sun, 30 Jan 2022 17:02:02 +0000 Received: (at 53526) by debbugs.gnu.org; 30 Jan 2022 17:01:59 +0000 Received: from localhost ([127.0.0.1]:37514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEDaR-000626-F0 for submit@debbugs.gnu.org; Sun, 30 Jan 2022 12:01:59 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4717) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEDaO-00061o-3U for 53526@debbugs.gnu.org; Sun, 30 Jan 2022 12:01:57 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 12275100189; Sun, 30 Jan 2022 12:01:50 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 77FDB10008C; Sun, 30 Jan 2022 12:01:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1643562108; bh=DD/SYXHJdIxbrEs35PNzxoZv7NyYQTwNAjAfU0mI7Zc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=D7J04xzS+2SV6IxfTyRpvtxLs/27zw6YTrFxwAc6GitRB3cu9C3gH6k4EFlt9yJ3o d7lctRydPLgGpMcHjU31p7xIwljQCUAvhQD3/HbeyDHM8Z2r0OTr9PRgMJoJjuUtwe NyTodWrS74FtzfDX4xa97JWHKrgmknacd1U4/9ezyRKu1E7J9Un5adz/5muV4DnBnF T6EgtUdmD7jfZe0hPee8FFZwSZPoXyEwAP02vPXkM+eeD67d10R6JgYFOS6Dk9/8gJ FAeq14dHwlzAL/0iSXwHWZHBb98RAVO0dKrqDTMT+MwEQ2wgFH8M/NfCsMIep0K7vY 3Y9V5RBBTugNA== Received: from pastel (76-10-138-212.dsl.teksavvy.com [76.10.138.212]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4BB7312084D; Sun, 30 Jan 2022 12:01:48 -0500 (EST) From: Stefan Monnier Message-ID: References: Date: Sun, 30 Jan 2022 12:01:46 -0500 In-Reply-To: (Alan Mackenzie's message of "Sun, 30 Jan 2022 13:34:00 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.009 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> No, its name was changed from "macroexp--" to "macroexp-" in Emacs-28, >> specifically to make available for third party packages. It was >> announced in etc/NEWS, for example. > Are you aware of it being used anywhere else but lisp/emacs-lisp? Yes and no: there's a use of `macroexp--warn-and-return` in `peg.el` (in GNU ELPA). This should be updated to use `macroexp-warn-and-return` when Emacs-28 is released. But changing the API this way will discourage its use outside of Emacs since it's be a pain to write code that deals with such changes (short of imposing Emacs-29 as the minimum supported version). >> Still, the current setup is really ugly: that var belongs in >> `bytecomp.el`. > Well, I suppose it could be defined in bytecomp.el and just declared in > macroexp.el. That's all we need. > It's not going to get used before it's been initialised in > bytecomp.el. If that's the case, it's even better. >> I'd put a double hyphen there simply because it's not something that we >> want to expose as an official API. Just because the bytecompiler's >> macroexpansion phase is implemented in a separate file doesn't justify >> making the var public. > OK, we can mange that. Thanks. > I suspect the difficulty in understanding this facility will have > strongly dissuaded any external hackers from attempting to use it. Could be. I suspect it's more a lack of exposure and the fact that most macros are quick hacks that don't bother to perform much checking. But it's definitely a facility that's useful for libraries that mostly define a DSL via macros, like `peg.el` and `bindat.el`. Stefan