From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#70368: [PATCH] Use a dedicated type to represent interpreted-function values Date: Mon, 15 Apr 2024 14:23:58 +0300 Message-ID: <86sezmlvht.fsf@gnu.org> References: <86il0ko6f9.fsf@gnu.org> <86h6g4m29n.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14965"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70368@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 15 13:25:24 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 1rwKSi-0003ge-6Z for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Apr 2024 13:25:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rwKSO-0000J8-Og; Mon, 15 Apr 2024 07:25: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 1rwKSM-0000It-Ro for bug-gnu-emacs@gnu.org; Mon, 15 Apr 2024 07:25:02 -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 1rwKSM-0002BA-In for bug-gnu-emacs@gnu.org; Mon, 15 Apr 2024 07:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rwKSX-0001pO-OW for bug-gnu-emacs@gnu.org; Mon, 15 Apr 2024 07:25:13 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Apr 2024 11:25:12 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70368 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 70368-submit@debbugs.gnu.org id=B70368.17131802906831 (code B ref 70368); Mon, 15 Apr 2024 11:25:12 +0000 Original-Received: (at 70368) by debbugs.gnu.org; 15 Apr 2024 11:24:50 +0000 Original-Received: from localhost ([127.0.0.1]:36979 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rwKRz-0001l9-RM for submit@debbugs.gnu.org; Mon, 15 Apr 2024 07:24:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35612) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rwKRn-0001hi-92 for 70368@debbugs.gnu.org; Mon, 15 Apr 2024 07:24:36 -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 1rwKRV-000245-Bw; Mon, 15 Apr 2024 07:24:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=lf53TieTK7Zti3NYTU2uKkyXC14+LfJc9XIBf7BD+2c=; b=gXtxqSXx6VSE QM/+pz3SwnWvpvJ8xCSR60iMECzDr9RnqBOIucz1OK6gPxgUyAPt+mU78H81HcF5ODxGfKi4rv2X8 ofj6IamWrAA7HGL5RdmlMgaZ65NqyOcMMdlMYt97N9loS+Uez+7oHv0aAhYvfXsJSSBsROhRqvm0u irM+CL64JmLuV2hykV3FBSKuuuZvWgBC3mO2kGxYp57BshLtqHNoOCwR13k3zWuxOigUtMC6zwuE6 rP4xYpbrjdCudGP+/uimrKhxe38EfKLP3/2tEA8xmpJ4gQjVqaKvE9K5R2pE246OPsl2Uh9jsiIIa y/39jONgYRuq/d3ircwkUg==; In-Reply-To: (message from Stefan Monnier on Sun, 14 Apr 2024 19:03:57 -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:283356 Archived-At: > From: Stefan Monnier > Cc: 70368@debbugs.gnu.org > Date: Sun, 14 Apr 2024 19:03:57 -0400 > > >> - "soft" incompatibilities for code which tries to display the kind of > >> the object it receives (such as in a completion table that wants to > >> add an icon indicating if something is a macro, a compiled function, > >> etc...). Such code will still work but may display less informative > >> info because it may fail to recognize the new objects as being > >> interpreted functions. > >> - "real" incompatibilities for code which digs inside the > >> entrails of functions to try and extract specific information. > >> This may fail when faced with the new interpreted functions > >> but should be easy to fix. > >> As long as such code only tries to extract info and does it via > >> `help-function-arglist`, `documentation`, and `interactive-form`, > >> there's no problem, but some packages may use code inherited from > >> a long time ago when `help-function-arglist` didn't exist, or written > >> by coders who didn't know better. I know Hyperbole used to do that, > >> but I believe that's been fixed since. > >> - "hard" incompatibilities for code which really digs inside the > >> code of functions. `vc.el` did that a long time ago, > >> `kmacro.el` did as well until OClosures, and Buttercup (a NonGNU ELPA > >> package) did until a few months ago. There are probably one or two > >> packages out there that will be affected like Buttercup would have > >> been. FWIW, the Buttercup case was a mix of "hard" and "soft": it > >> really looked inside the code, but used that only to provide more > >> informative messages and had a fallback case when the code was > >> compiled, so it would still work OK. > > > > Some of the above should be in NEWS, I think, in the "incompatible > > Lisp changes" section. > > I don't really know what more I could put in there. The entry I added > states the actual changes and the above "two" are just > direct consequences. I think the only problems we need to mention are those with Lisp programs that "dig" inside the code of functions. I think it should be enough to give one or two concrete examples (what internals the offending code depended on), and tell that these techniques will no longer work. You mention above examples of packages that used to do it, but that's not useful; providing specific examples of what those packages did will explain the problems much better. > How do you imagine a user or developer is going to make use of the > above info? They will realize which techniques are no longer supposed to work, and could look into their code to try find such techniques. > > I think this also calls for augmenting the documentation of > > make-byte-code to the effect that it could now create closures as > > well. > > I'm not very happy documenting it, because I think it's an > implementation accident resulting from the historical evolution of > the code. IOW something we may want to fix. Then maybe a defalias with a suitable name could be the first step in that direction? I suggested documenting it because the name of the function no longer describes accurately what it does, and people might be surprised to see that it is used to create something other than byte-code.