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#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects) Date: Fri, 5 Jul 2024 21:41:25 +0000 Message-ID: References: <87zfqwh1gb.fsf@web.de> <86o77c75jd.fsf@gnu.org> 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="15275"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Michael Heerdegen , acm@muc.de, Eli Zaretskii , Andrea Corallo , 71934@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 05 23:42:18 2024 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 1sPqh8-0003qU-23 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Jul 2024 23:42:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sPqgr-0006Lj-4a; Fri, 05 Jul 2024 17:42:01 -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 1sPqgq-0006LR-6l for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2024 17:42:00 -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 1sPqgp-0002uA-Um for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2024 17:41:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sPqgs-0004Mz-AI for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2024 17:42: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: Fri, 05 Jul 2024 21:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71934 X-GNU-PR-Package: emacs Original-Received: via spool by 71934-submit@debbugs.gnu.org id=B71934.172021569916763 (code B ref 71934); Fri, 05 Jul 2024 21:42:02 +0000 Original-Received: (at 71934) by debbugs.gnu.org; 5 Jul 2024 21:41:39 +0000 Original-Received: from localhost ([127.0.0.1]:45107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sPqgV-0004MJ-8U for submit@debbugs.gnu.org; Fri, 05 Jul 2024 17:41:39 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:39770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sPqgT-0004M6-8Y for 71934@debbugs.gnu.org; Fri, 05 Jul 2024 17:41:37 -0400 Original-Received: (qmail 4109 invoked by uid 3782); 5 Jul 2024 23:41:27 +0200 Original-Received: from muc.de (pd953a1ab.dip0.t-ipconnect.de [217.83.161.171]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 05 Jul 2024 23:41:27 +0200 Original-Received: (qmail 30510 invoked by uid 1000); 5 Jul 2024 21:41:26 -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:288438 Archived-At: Hello, Stefan. On Fri, Jul 05, 2024 at 16:26:02 -0400, Stefan Monnier wrote: > >> (closure ...) is not a function symbol nor a valid form. Instead it's > >> a function value and the docstring doesn't say such are > >> a valid arguments to `native-compile`. > > All very clever arguments, no doubt, but in the end it means you cannot > > native compile foo. > To obey the docstring, .... Forget that doc string, just do what is right, expected, and convenient for Emacs users, and adjust the doc string afterwards. > > I've just tried it on emacs-30, and it doesn't work. > As it is allowed to, according to its docstring. Forget that doc string. It belongs to lawyers, not reality. > > But you could compile foo last summer after my fixes for bug #64646. > [ But that still failed to make it work for byte-compiled function values, > and it failed to update the docstring to announce that new behavior. ] That is a strawman. You have never been able to compile from byte-compiled code to native compiled code, and never will (unless Andrea has anything new to the contrary to say). The point is being able to compile foo, from read source code. You don't want to be able to do this for reasons I can't fathom. > >> Admittedly, maybe we should extend `native-compile` to accept function > >> values, just like `byte-compile`. > > Or something like that, yes. But if logical combinations of terms like > > "form", "closure", "function value", "valid form" lead to not being able > > to compile foo, then I suggest that these terms and their applicability > > might need to be thought through somewhat. > Don't worry: they've been thought through aplenty. Clearly not. The confusion they're apparently causing is affecting Emacs. > >>> So I fixed comp--spill-lap-function (form version) so as to compile > >>> that form. > >> Why `comp--spill-lap-function` specifically (instead of > >> `native-compile`, for example)? > > I fixed what was wrong at the time. > I'd like to implement the feature of `native-compile` accepting function > values correctly rather than in the most expedient way. If you could > try to remember why you fixed it in this specific way, .... I have no records of my reasons. Having diagnosed the problem, it was not difficult to fix. I just fixed it in the simplest, most obvious, and most obviously correct way. > .... that would be very helpful, because I'm not sufficiently familiar > with the code of `comp--spill-lap-function` to be sure of what I'm > doing. > >> > I've no idea how Emacs would handle that defconst now. > >> Hmm... AFAICT your example doesn't relate to `defconst`. > >> You'd get the same result with > >> M-: (native-compile (lambda (baz) (car baz))) RET > > Whatever. foo doesn't compile; that should be fixed. > All I'm saying is that it's a feature request, rather than a bug to > be fixed. Functionality has been lost. Finding an excuse in the exact meaning of words rarely used with such precision is not a way to restore that functionality. > Stefan -- Alan Mackenzie (Nuremberg, Germany).