From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function Date: Sun, 13 Aug 2023 10:10:30 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16936"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 65017@debbugs.gnu.org, Eric Marsden To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 13 12:11:16 2023 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 1qV843-0004HL-TG for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 13 Aug 2023 12:11:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qV83s-0002H6-Ge; Sun, 13 Aug 2023 06:11:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qV83q-0002Gr-H8 for bug-gnu-emacs@gnu.org; Sun, 13 Aug 2023 06:11:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qV83q-0004uv-7A for bug-gnu-emacs@gnu.org; Sun, 13 Aug 2023 06:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qV83q-0006Qw-26 for bug-gnu-emacs@gnu.org; Sun, 13 Aug 2023 06:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Aug 2023 10:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65017 X-GNU-PR-Package: emacs Original-Received: via spool by 65017-submit@debbugs.gnu.org id=B65017.169192144024694 (code B ref 65017); Sun, 13 Aug 2023 10:11:02 +0000 Original-Received: (at 65017) by debbugs.gnu.org; 13 Aug 2023 10:10:40 +0000 Original-Received: from localhost ([127.0.0.1]:58294 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qV83T-0006QC-Si for submit@debbugs.gnu.org; Sun, 13 Aug 2023 06:10:40 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:30935) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qV83R-0006Pw-Qx for 65017@debbugs.gnu.org; Sun, 13 Aug 2023 06:10:39 -0400 Original-Received: (qmail 90089 invoked by uid 3782); 13 Aug 2023 12:10:31 +0200 Original-Received: from acm.muc.de (p4fe152a2.dip0.t-ipconnect.de [79.225.82.162]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 13 Aug 2023 12:10:31 +0200 Original-Received: (qmail 17114 invoked by uid 1000); 13 Aug 2023 10:10:30 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:267354 Archived-At: Hello, Stefan. On Sat, Aug 12, 2023 at 14:28:44 -0400, Stefan Monnier wrote: > >> I couldn't really think of any alternative for IT ("it" being to > >> implement `cl-labels` and `cl-flet`). FWIW, the pre-cl-lib code > >> did IT differently by duplicating `macroexp--expand-all` wholesale > >> and then tweaking its handling of `function` in an ad-hoc way. > > Your reply doesn't address my question. It is not clear to me what > > the IT in your previous paragraph is. You may or may not have > > thought of some alternative for IT, and previous code may have done > > IT differently, but that doesn't help me understand what IT is. > > What was the difficulty in cl-labels and cl-flet for which IT and > > cl--labels-convert was the solution? > > The code is substituting (function F) with a non-eq (function F). > > You're saying this has some effect in macroexp--expand-all. I can't see > > that, yet. All I see is FORM, (function F), being substituted by a > > different (function F) in L327 of macroexp.el. Then there are the pcase > > arms for (function (lambda ....)) and for (function ....). Are either > > of these pcase arms affected by the "expansion" of FORM? If so, how? > > Or am I looking at the wrong place entirely? > `cl-flet` needs to replace (function LOCALFUN) with LOCALVAR within the > body of the let, for those LOCALFUNs defined in the `cl-flet`. > That's easy to do with a macro. > But it also should leave all other uses of `function` untouched. > That's the part that does not map well to macros since macros are > repeatedly expanded until they return something that's not a macro call. Thanks, that's useful information. But it doesn't address my questions in the slightest. This is the third time I'm asking you for help. I thought it would be quicker than figuring everything out on my own. You wrote the code, I think. I don't understand how cl--labels-convert works, down at the car and cdr level. I'm asking you to help me, but I'm not sure how sensible it is to carry on asking repeatedly. I've replaced two paragraphs you snipped from your last reply. Would you please answer these specific questions, now, to help me understand this difficult mechanism. Thanks! > >> It's not a function but a special operator, which is thus handled in > >> a hard-coded way by `macroexp--expand-all`. > > Is it the case that this hard-coded handling for function is prevented > > by the macro "expansion" of (function F)? > Yes, we first expand the macros and then try to handle the result > which should be one of the hard-coded cases (or is otherwise assumed to > be a function call). Are you talking about the code in macroexp--expand-all, here? By "macros", do you mean cl-flet and cl-labels here (as opposed to function)? What do you mean by "hard-coded cases"? Do you mean the pcase arms in macroexp--expand-all? If so, which ones? > Stefan -- Alan Mackenzie (Nuremberg, Germany).