From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo 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: Tue, 09 Jul 2024 16:49:26 -0400 Message-ID: References: <87zfqwh1gb.fsf@web.de> <86o77c75jd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13344"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Michael Heerdegen , Eli Zaretskii , Stefan Monnier , 71934@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 09 22:52:29 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 1sRHp7-0003E4-5u for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Jul 2024 22:52:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sRHoe-0004Hc-FN; Tue, 09 Jul 2024 16:52:00 -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 1sRHoc-0004HC-70 for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2024 16:51:58 -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 1sRHob-0004Gh-Ry for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2024 16:51:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sRHog-0006D9-Gh for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2024 16:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Jul 2024 20:52: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.172055831323860 (code B ref 71934); Tue, 09 Jul 2024 20:52:02 +0000 Original-Received: (at 71934) by debbugs.gnu.org; 9 Jul 2024 20:51:53 +0000 Original-Received: from localhost ([127.0.0.1]:54225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRHoX-0006Cm-0q for submit@debbugs.gnu.org; Tue, 09 Jul 2024 16:51:53 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36222) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRHoV-0006CZ-Fz for 71934@debbugs.gnu.org; Tue, 09 Jul 2024 16:51:52 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRHmB-0003oU-UI; Tue, 09 Jul 2024 16:49:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=Py/HQEiGFDQ9qDqlFVb0yaf8KejW6XJaa71W7lc1ccE=; b=AgEnb4fy7dqlOMeTcY9K jWNhOXECGzvZ+MhiT56HwGmnrSpyszsBD06hnEvPOWVomhiWo041MtcNxVMtiJrdWx5VrI4QjVzmh qDWvQhGJkzI9a70GjWkj2ZIyQf5ooc/V5xkpggCxRbe+hXx6eWAL6VjTBx0fyOeku4BC3yvSh6wvm mBDS/lHl4IocI24lJeOUNzAC5Ye6BK3L1I4j1Sc2UUFXntKTqkjQf40PvKeFV/7ZHyGLoCCbhF55L K3T175c8dpN+KSYZXZOdgdtDqOXukGVYRy2QbCmKxK0uOow6snN1rSKlBELhG567OQtlWWwfiO40K 8Usf+xefShlyHg==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1sRHmA-0002rP-U3; Tue, 09 Jul 2024 16:49:27 -0400 In-Reply-To: (Andrea Corallo's message of "Sat, 06 Jul 2024 13:29:01 -0400") 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:288655 Archived-At: Andrea Corallo writes: > Alan Mackenzie writes: > >> Hello, Andrea. >> >> On Sat, Jul 06, 2024 at 03:48:50 -0400, Andrea Corallo wrote: >>> Alan Mackenzie writes: >> >>> > Hello, Stefan. >> >>> > On Fri, Jul 05, 2024 at 14:17:38 -0400, Stefan Monnier wrote: >>> >> > Not sure what you mean by "no such thing as a form ... like a closure". >> >>> >> A form that starts with `closure` is not a valid form because there is >>> >> no definition for `closure`: (fboundp 'closure) => nil. >> >>> >> > I bumped into one last summer. >> >>> >> > In particular (in my development repo fixing bug #64646) I put this into >>> >> > *scratch*: >> >>> >> > (defconst foo (lambda (baz) (car baz))) >> >>> >> > , evaluated it with C-x C-e and then M-: (native-compile foo). This >>> >> > threw the error "Cannot native-compile, form is not a lambda". >> >>> >> That error seems right according to the docstring: >> >>> >> (defun native-compile (function-or-file &optional output) >>> >> "Compile FUNCTION-OR-FILE into native code. >>> >> This is the synchronous entry-point for the Emacs Lisp native >>> >> compiler. FUNCTION-OR-FILE is a function symbol, a form, or the >>> >> filename of an Emacs Lisp source file. If OUTPUT is non-nil, use >>> >> it as the filename for the compiled object. If FUNCTION-OR-FILE >>> >> is a filename, if the compilation was successful return the >>> >> filename of the compiled object. If FUNCTION-OR-FILE is a >>> >> function symbol or a form, if the compilation was successful >>> >> return the compiled function." >> >>> >> (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. I've just tried it on emacs-30, and it doesn't work. >>> > But you could compile foo last summer after my fixes for bug #64646. >>> > Between last summer and now, something has gone badly wrong in Emacs's >>> > basic mechanisms. >> >>> (defconst foo (lambda (baz) (car baz))) >>> (native-compile #'foo) >> >>> Never worked AFAIR, .... >> >> No. But (native-compile foo) did work. It compiled the value of foo, >> producing an anonymous subr. >> >>> ....the functionality you added was: >> >>> (defun foo () "foo doc string" >>> (lambda () "lambda doc string" 3)) >> >>> (subr-native-elisp-p (funcall (native-compile 'foo))) >> >> Yes. >> >>> And this still works for me. >> >> It still works for me, too. >> >>> I'm probably missing something sorry. >> >> The fact that >> >> (defconst foo (lambda (baz) (car baz))) >> (native-compile foo) >> >> worked (as of 2023-11-08), but no longer does. It was not the main topic >> of bug #64646 (for which see above), but was fixed in the commit for that >> bug anyway. This was possibly not a good idea. That commit was: >> >> commit 06e4ebc81a44c709b08ce72c746629c6c77e6f6e >> Author: Alan Mackenzie >> Date: Wed Nov 8 20:49:48 2023 +0000 >> >> With `native-compile', compile lambdas in a defun or lambda too > > Thanks I see now, at least we never regressed over releases. > > I think this functionaly passed under my radar at the time, otherwise I > would have asked for a test covering it, and BTW as a consequence Stefan > would have updated the implementation before upstreaming his patch :) > > Anyway as > (defconst foo (lambda (baz) (car baz))) > (byte-compile foo) > works, I is nice to have it functional for native-comp as well. > > Reintroducing it should not be too difficult, I can do it myself next > week if no-one does it before. Okay should be done with b9b9322a8e6 in master adding a test and updating 'native-compile' doc-string. Is there anything left to do for this bug? Andrea