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: Sat, 06 Jul 2024 13:29:01 -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="1401"; 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 Sat Jul 06 19:30: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 1sQ9En-0000Az-Up for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jul 2024 19:30:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQ9EW-0007a2-St; Sat, 06 Jul 2024 13:30: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 1sQ9EV-0007Zj-BI for bug-gnu-emacs@gnu.org; Sat, 06 Jul 2024 13:29:59 -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 1sQ9EU-0007Bu-Vq for bug-gnu-emacs@gnu.org; Sat, 06 Jul 2024 13:29:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sQ9EY-0007K7-FP for bug-gnu-emacs@gnu.org; Sat, 06 Jul 2024 13:30: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: Sat, 06 Jul 2024 17:30: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.172028695628063 (code B ref 71934); Sat, 06 Jul 2024 17:30:02 +0000 Original-Received: (at 71934) by debbugs.gnu.org; 6 Jul 2024 17:29:16 +0000 Original-Received: from localhost ([127.0.0.1]:46719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQ9Do-0007IX-0f for submit@debbugs.gnu.org; Sat, 06 Jul 2024 13:29:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34192) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQ9Dl-0007II-JK for 71934@debbugs.gnu.org; Sat, 06 Jul 2024 13:29:14 -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 1sQ9Dc-00070O-FH; Sat, 06 Jul 2024 13:29:04 -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=P+HFc0l9Ywv4ko3itUXpVCV9shdVzi9Up3I5RoBnjAg=; b=qHDJ9XKD5HeV6mradfEQ MhynS6exqTtUE9NmdjfdPcg6ln0l86IzkL2aG4wxY2888pUtx7olH/8oc3HC4CNBXaPDIlF55dVq5 OrefRdQWCCeAd0FTDJ8ao09+POWoHdhLdzisAhOEukEfcNkqhClE6+m3he9HNDsDj96+d+7xwOADd mEjJzhu6kLBiK0KOyAkSLllUHFegFun11OghM/sDBf3oZFHZg0feAeJ21jSrhwquETbIk+Z6zD4nk ECnrJ7623UGAkYAfJlgwXyep2KLfoSSlEy8Gfhs03+gYUUS1/LfU+jbi+hdCwQKYnoXLpT0AMhPMt hdTbuaQjb4pb/Q==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1sQ9Da-0005yj-12; Sat, 06 Jul 2024 13:29:02 -0400 In-Reply-To: (Alan Mackenzie's message of "Sat, 6 Jul 2024 11:01:34 +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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:288515 Archived-At: 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. Thanks Andrea