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#54079: 29.0.50; Method dispatching eratically fails Date: Fri, 11 Mar 2022 23:23:50 -0500 Message-ID: References: <87k0d7257t.fsf@web.de> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35480"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Michael Heerdegen , Lars Ingebrigtsen , 54079@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 12 05:25:16 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 1nStJb-000927-V1 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 12 Mar 2022 05:25:16 +0100 Original-Received: from localhost ([::1]:44346 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nStJa-00058f-Hm for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 11 Mar 2022 23:25:14 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37356) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nStJO-00058P-U1 for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2022 23:25:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45059) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nStJO-0000qR-KB for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2022 23:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nStJO-000892-Fl for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2022 23:25:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Mar 2022 04:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54079 X-GNU-PR-Package: emacs Original-Received: via spool by 54079-submit@debbugs.gnu.org id=B54079.164705904231233 (code B ref 54079); Sat, 12 Mar 2022 04:25:02 +0000 Original-Received: (at 54079) by debbugs.gnu.org; 12 Mar 2022 04:24:02 +0000 Original-Received: from localhost ([127.0.0.1]:38956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nStIQ-00087Y-0j for submit@debbugs.gnu.org; Fri, 11 Mar 2022 23:24:02 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45589) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nStIN-00086z-So for 54079@debbugs.gnu.org; Fri, 11 Mar 2022 23:24:00 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id ED0258051E; Fri, 11 Mar 2022 23:23:53 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E563C802B7; Fri, 11 Mar 2022 23:23:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1647059031; bh=wVa+IGET3DORLjBd397nifoRzQ7qb7E5hwzk2dfwfFI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=pMF41OaAtCbFwEJdW+P3jEPY4xA5RyMcyD2TJd68wldPazKdW9YSSZloNCl8ieyKi N1lZMyQMhCl3x4TL14EmqlTrU0FIyNLPoK+gW5lD8x2opcpy6dg0dpEy/c/3Sr/WjR oUBnihOCDqV79I89tcR7l/6MpN9EGRdxb5T1N0iN8M2qszfezN8oAdYEvabW9ExmN2 UHDg7sdbuLKslUAA+vBYnO4MjZe43NTFUfq5/rK6qXhk1HNZVPsHz787Ygoz3WsvKE k6ELFxKpacodFIAyuSpDmxWP3oMFDk4jD3czlr6jE0+U0aLwRawRTPamizZs9G4VZe 21gHD6M+gidGA== Original-Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AC0AC120235; Fri, 11 Mar 2022 23:23:51 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Fri, 11 Mar 2022 22:01:41 +0000") 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:228243 Archived-At: >> I'm not sure what "such a case" you're thinking of. > > One of the "99% other cases that *do* occur" that you referred to in your > previous paragraph. You say that these wouldn't "work right". I'm > asking you for an example of such a "not working right". (defalias 'FOO BAR) >> But in general, evaluation of code doesn't expect symbols to have >> positions: > > The evaluation is completely indifferent to the SWPs, when > symbols-with-pos-enabled is t. While evaluating (defalias 'FOO BAR) everything will be dandy. But when you later call FOO while `symbols-with-pos-enabled` is not t anymore, then things go haywire. Same with (put FOO BAR (lambda ...)) or (add-hook FOO (lambda ...)) or (setcdr FOO (lambda ...))) or ... Of course, similar thing will go wrong without `lambda` because for example (setq FOO 'bar) will set FOO to `bar`-with-pos, so when you later compare FOO to `bar` you will find that `eq` will say nil. Etc... the list goes on and on. >> ... it may test `eq` between symbols and it may be run without having >> the magical `symbols-with-pos-enabled`. > I've lost the thread here. What scenario are you considering? I thought > we were talking only about the `eval' within eval-{when,and}-compile. Whatever appears in the code passed through `eval-{when,and}-compile` can survive that code, so the fact that `symbols-with-pos-enabled` is non-nil while evaluating it doesn't make it correct. >> So as a general rule we should strip symbols before we pass it to `eval`. > I don't see this, due to all the confusion we're experiencing. As a > general rule, within byte compilation, symbol stripping should be > postponed as long as possible whilst a compilation of the form is still > possible. `eval` is exactly this "as long as possible" point where we know the code won't be compiled because it's about to be interpreted. > But, looking at the code, I don't think byte-compile binds > symbols-with-pos-enabled to t. This could be a bug. Maybe not: it has no reason to presume that its argument has positions. If it does, then it must be because the caller explicitly arranged for it to happen and so the caller could be in charge of binding that variable. >> And why bother stripping the result of `byte-compile-eval`? > > (This is in eval-when-compile only.) That result may contain SWPs. For > example: > > (eval-when-compile (cons 'foo 'bar)) But the result is then passed to the compiler anyway, so this is the same as writing '(foo bar) which will come "with pos", so I still don't see why we'd need to strip pos from the result here. Even more so because the code passed to `byte-compile-eval` is compiled so it presumably doesn't have any sympos anyway, so there shouldn't be any sympos in its output either anyway. >> Fundamentally, `eval` should always strip before doing its job. > You mean, by "always", you meant ALWAYS??? Yes. > I understood you to mean "always, when in the context of > eval-{when,and}-compile". If we're not inside a compilation, and thus > there're no SWPs hanging around, stripping symbols from an expression > will just mean a loss of time for a null operation. That's right: the only cases where not stripping the arg of `eval` is OK is when we know that stripping would do nothing. IOW it's an optimization. > At the moment, I disagree with you. I don't think you have given an > example of a form FOO which will only work if stripping is done before > evaluation in > > (eval-when-compile FOO) > > or > > (eval-and-compile FOO) > > .. At the moment, I still think it is better to strip the positions after > the evaluation. And I still haven't heard any good reason why stripping them after the evaluation would be of any use since that result is passed to the compiler which is perfectly happy to accept code-with-pos. >> The misbehavior I'm referring to is what happens when you call the >> function before you byte-compile it (or, more likely, when you never end >> up byte-compiling it), because the presence of sympos in the function >> will mess up its semantics (because `symbols-with-pos-enabled` won't be >> set any more when it's called). > > I'm puzzled. Are we still talking about eval-{when,and}-compile, here? No. We're talking about a hypothetical case where `(eval '(defun foo ...))` is executed somehow and where the `(defun foo ...)` part somehow contains symposes. I used it as an example of why `eval` should conceptually always strip its argument (or if `eval` doesn't do it, then its caller should make sure that the code passed to it doesn't contains symposes). >From what I understand you suggested that in that cases `eval` should preserve the symposes in the hope that the user later calls `(byte-compile 'foo)` which can then benefit from those symposes to give better warnings. And I pointed out that this still means that (until that `byte-compile` call comes) the code of `foo` will likely be broken so any uses of `foo` will likely misbehave. > If so, how can a form with SWPs get into a symbol's function cell? > The positions are stripped inside the e-w/a-compile. Hmm... I agree that the positions *should* be stripped inside e-w/a-compile before passing the code to `eval`, but the code I see right now in bytecomp.el says: (eval-and-compile . ,(lambda (&rest body) (byte-compile-recurse-toplevel (macroexp-progn body) (lambda (form) ;; Don't compile here, since we don't know ;; whether to compile as byte-compile-form ;; or byte-compile-file-form. (let* ((print-symbols-bare t) ; Possibly redundant binding. (expanded (macroexpand--all-toplevel form macroexpand-all-environment))) (eval expanded lexical-binding) expanded))))) I don't see where the symbols are stripped before passing the code to `eval`. So if `form` is of the form `(defun foo ...)` I think we have a problem. > (eval-when-compile > (fset 'foo '(defun bar ....))) > > , where SWPs will escape into foo. Why do you need the `put` in there? Doesn't the same problem show up with (eval-and-compile (defun bar ....)) which does not seem "vanishingly unlikely" at all. Stefan