From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#57397: cl-letf blindly macroexpands places Date: Sat, 03 Sep 2022 22:55:53 -0400 Message-ID: References: <877d2xdjdi.fsf@web.de> <87leralavg.fsf@web.de> <87sfldmc43.fsf@web.de> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32114"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 57397@debbugs.gnu.org, Lars Ingebrigtsen To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 04 04:57:10 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1oUfos-0008CB-AI for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 04 Sep 2022 04:57:10 +0200 Original-Received: from localhost ([::1]:34442 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oUfoq-0003pA-HX for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 03 Sep 2022 22:57:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43200) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oUfok-0003nh-HN for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2022 22:57:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54531) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oUfok-0001t2-8h for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2022 22:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oUfok-00039m-0d for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2022 22:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Sep 2022 02:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57397 X-GNU-PR-Package: emacs Original-Received: via spool by 57397-submit@debbugs.gnu.org id=B57397.166226016612066 (code B ref 57397); Sun, 04 Sep 2022 02:57:01 +0000 Original-Received: (at 57397) by debbugs.gnu.org; 4 Sep 2022 02:56:06 +0000 Original-Received: from localhost ([127.0.0.1]:43230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oUfnq-00038Y-DS for submit@debbugs.gnu.org; Sat, 03 Sep 2022 22:56:06 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:5779) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oUfnm-000380-7u for 57397@debbugs.gnu.org; Sat, 03 Sep 2022 22:56:04 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6D3271001D2; Sat, 3 Sep 2022 22:55:56 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D4A30100154; Sat, 3 Sep 2022 22:55:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1662260154; bh=oAuGiVhznoXWGrLkJzjHIx7hhxuKbhGRYXrIPJyFk3k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Th3nbxc4EbZX5lqj4DLi02thRpGJF0vB629H4oZSlqrkEIIc0w9hhRz00qAmUnNwL tjq0t6cUFtoOdSKQW0QvPWVHnSjUcgZs+4a0Vy+Zaj0Z+C83jl9q0psm1olrtGNVmK wg7Iokv23XATJwf4q77Yx8nEH7jwVK7RjT6E0byGp99F8OIC2wWDaf7FAnRf3NpN8h h3L+Tzs2KMotHBdgzUiSyRRMZvwlw2TgG9h4db06yM0CG26Z9vqzj8/BNw7sAzqvDp Ba7Jfz0MCvYt4vP/lPSY7+JPkdYUCCTwEKVKDwdF08NCMeV2WW9LYSBR9JFqzPc5hV tIDWCrwq1Ystw== Original-Received: from pastel (unknown [157.52.9.190]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A9776120840; Sat, 3 Sep 2022 22:55:54 -0400 (EDT) In-Reply-To: <87sfldmc43.fsf@web.de> (Michael Heerdegen's message of "Wed, 31 Aug 2022 03:32:28 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:241458 Archived-At: >> No the problem shows up in the `gv-letplace` that follows immediately, >> so by the time we get to the `symbolp` test it's too late. >> But I suspect that the better fix is to skip the macroexpand call here >> and to change `gv-get` so as to do a `macroexpand-1` call even if its >> arg is a `symbolp`. > > Ok, you have obviously more insight here, so can you maybe...take over > this part? Pushed to `master`. > Ok - does this look correct? Looks good, yes. > BTW, I had trouble understanding the paragraph about the compiler-macro > declare specs in (info "(elisp) Declare Form"), in particular the calling > convention: > > | [...] When encountering a call to the function, of the form =E2=80=98(F= UNCTION > | ARGS...)=E2=80=99, the macro expander will call EXPANDER with that form= as > | well as with ARGS... > > not only because of the colons, but also because it's...wrong? EXPANDER > is called with one argument, and the other formal arguments are > available (bound) to the corresponding argument forms, right? There are two cases: one is when EXPANDER is of the form (lambda ...) and the other is when it's not (in which case it'll be a symbol naming a function defined elsewhere). When you write (defun my-foo (arg1 &optional arg2) (declare (compiler-macro (lambda (whole) ..blabla..))) ..toto..) it is macro expanded to something more or less equivalent to: (defun my-foo (arg1 arg2) (declare (compiler-macro my-foo--expander)) ..toto..) (defun my-foo--expander (whole arg1 &optional arg2) ..blabla..) > Could you then maybe rephrase a bit [I don't want to, my English is not > good enough. I'm able to do it but it always takes much too long to > find a good wording.] I can see the source of your confusion, but I'm not sure how to write it better, without making it much more verbose (and risk making it yet more confusing). Would something like the patch below help? Stefan diff --git a/doc/lispref/functions.texi b/doc/lispref/functions.texi index 983dfe2ec59..8e34fdf3640 100644 --- a/doc/lispref/functions.texi +++ b/doc/lispref/functions.texi @@ -2476,11 +2476,11 @@ Declare Form expander will call @var{expander} with that form as well as with @var{args}@dots{}, and @var{expander} can either return a new expression t= o use instead of the function call, or it can return just the form unchanged, -to indicate that the function call should be left alone. @var{expander} c= an -be a symbol, or it can be a form @code{(lambda (@var{arg}) @var{body})} in -which case @var{arg} will hold the original function call expression, and = the -(unevaluated) arguments to the function can be accessed using the function= 's -formal arguments. +to indicate that the function call should be left alone. + +To avoid syntactic redundancy, when @var{expander} is of the form +@code{(lambda (@var{arg}) @var{body})} the function's formal arguments +are automatically added to the lambda's list of arguments. =20 @item (gv-expander @var{expander}) Declare @var{expander} to be the function to handle calls to the macro (or