From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#57397: cl-letf blindly macroexpands places Date: Wed, 28 Sep 2022 19:52:00 +0300 Message-ID: <835yh7igr3.fsf@gnu.org> References: <877d2xdjdi.fsf@web.de> <87leralavg.fsf@web.de> <87sfldmc43.fsf@web.de> <87tu4rbj1t.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38321"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael_heerdegen@web.de, 57397@debbugs.gnu.org, larsi@gnus.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 28 20:31: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 1odbpt-0009pe-IT for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Sep 2022 20:31:09 +0200 Original-Received: from localhost ([::1]:41846 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odbps-0005px-6U for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Sep 2022 14:31:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56830) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odaIy-0008Sk-Iq for bug-gnu-emacs@gnu.org; Wed, 28 Sep 2022 12:53:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35363) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1odaIx-0002Hu-12 for bug-gnu-emacs@gnu.org; Wed, 28 Sep 2022 12:53:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1odaIw-0005K5-Er for bug-gnu-emacs@gnu.org; Wed, 28 Sep 2022 12:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Sep 2022 16:53:02 +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.166438393820408 (code B ref 57397); Wed, 28 Sep 2022 16:53:02 +0000 Original-Received: (at 57397) by debbugs.gnu.org; 28 Sep 2022 16:52:18 +0000 Original-Received: from localhost ([127.0.0.1]:34441 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1odaID-0005J6-Nn for submit@debbugs.gnu.org; Wed, 28 Sep 2022 12:52:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1odaIA-0005It-Ip for 57397@debbugs.gnu.org; Wed, 28 Sep 2022 12:52:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55086) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odaI4-00029w-Dy; Wed, 28 Sep 2022 12:52:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Z6w2YwhjUY1YcTMeLkE4PoewDQXchE3AUPimPESf1jY=; b=AcUyPUsLJD8q6p/oqGut 39usNLd3CWJFIsFyJt3RtdP++8mKjtY6l6N5dHKKG2EvYnTEcroB+im8ecyuddK6AM0hVPTKxLTI7 3g2iD4+1FuOqa5iPafHuo1UP4uvyTr5sHKcu7jb0PyP/rypigDGVV7uv6xsK2Rd3XO+XlYNBEqjdx xNbCMMDWWfT6e3qH0FCZq+AoO9KQKEdr6JNjflOidpPb3cUXFES3kbqnN1Aga6zVWsc4nC3w5ihA5 ZjSWgO4Ac+Cr65gBsfeUcnX45a76GwaesxxXVmlHlMZMU8R0XTHtrrC6y5TF2j4dSKIqgrcTSi263 CbJobEhSiWJzBA==; Original-Received: from [87.69.77.57] (port=4818 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odaI2-0004Ny-P7; Wed, 28 Sep 2022 12:52:07 -0400 In-Reply-To: (bug-gnu-emacs@gnu.org) 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:243843 Archived-At: > Cc: 57397@debbugs.gnu.org, Lars Ingebrigtsen > Date: Wed, 28 Sep 2022 12:29:20 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > > But could we maybe describe that simpler like "when expander is a lambda > > form [...]"? - Because AFAIU these arguments are added to _any_ > > argument list - with other words, implicitly hint that it's an error to > > specify function arguments in the lambda arglist explicitly, or to > > provide an empty arglist. > > OK, thanks, done, IMO, the text which was installed looks devoid of any useful information: When EXPANDER is a lambda form it should be of the form ‘(lambda (ARG) BODY)’ because the function’s formal arguments are automatically added to the lambda’s list of arguments. Isn't every lambda form _always_ of that form? And "because" is out of the blue: there's no cause and effect relation here that I can identify. The original text was somewhat more self-explanatory: 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. This explains the reason, and actually reverses the cause and the effect, which then make sense. (Although the issue with the form of lambda still stands.) What am I missing?