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#54802: OClosure: Make `interactive-form` a generic function Date: Sat, 09 Apr 2022 08:58:09 +0300 Message-ID: <83czhqajda.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15194"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 54802@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 09 07:59:55 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 1nd48X-0003px-LX for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 09 Apr 2022 07:59:53 +0200 Original-Received: from localhost ([::1]:52944 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nd48W-0008QY-Dw for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 09 Apr 2022 01:59:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59168) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd47i-0008PY-NQ for bug-gnu-emacs@gnu.org; Sat, 09 Apr 2022 01:59:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42669) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nd47i-0001vH-CU for bug-gnu-emacs@gnu.org; Sat, 09 Apr 2022 01:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nd47i-0006bU-A3 for bug-gnu-emacs@gnu.org; Sat, 09 Apr 2022 01:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Apr 2022 05:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54802 X-GNU-PR-Package: emacs Original-Received: via spool by 54802-submit@debbugs.gnu.org id=B54802.164948388525317 (code B ref 54802); Sat, 09 Apr 2022 05:59:02 +0000 Original-Received: (at 54802) by debbugs.gnu.org; 9 Apr 2022 05:58:05 +0000 Original-Received: from localhost ([127.0.0.1]:36566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nd46m-0006aH-Jj for submit@debbugs.gnu.org; Sat, 09 Apr 2022 01:58:04 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nd46k-0006Zk-B8 for 54802@debbugs.gnu.org; Sat, 09 Apr 2022 01:58:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39800) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd46e-0001rY-AH; Sat, 09 Apr 2022 01:57:56 -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=yRCkC2niwfMtCRHxbdTPSmc3FYgaBYs1zsJrHPwT7Ts=; b=PzAG5AVMrEPX LeE+b7SFe9LuC7vynxCgNepCswRDsOOi7lhI5Z9HyBFywGcCfXy3XzTH/FJ19ffxCMn4XzGMAVYr1 bom1neKieySmodFg2A0b/s4lgdgGyFJhq3nsGN4qi9WZQWP/PjX/mifC5sz0JoHsML7CqZZUyCFvM HJ925CqqYry09EVfRkU7YC/jg5aNLUzU4pYFBRYaEuhq8wghJvuBAzW+H9ynap5fpMSGt7qSxMtrn 3WOAohP31v8qR5NtPMQX2LFdzSHNYtV/b4tqT9HaldljyoFtTrCv8j61PF/EgxYIFrXHGThWBKNsw vi9Wxjhb2zG6FOqwX5vZsg==; Original-Received: from [87.69.77.57] (port=1079 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd46d-0006Wa-PZ; Sat, 09 Apr 2022 01:57:56 -0400 In-Reply-To: (bug-gnu-emacs@gnu.org) 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:229597 Archived-At: > Date: Fri, 08 Apr 2022 16:33:51 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > `nadvice.el` needs to build commands whose interactive spec is computed. > This currently can't be done with `lambda` (see also bug#51695 for > a related problem) but `nadvice.el` is unaffected because it assembles > its byte-code functions all by hand. In order for `nadvice.el` to be > able to use OClosures, we need to address this limitation. > > The patch below does it by making `interactive-form` a generic function, > so OClosures can compute their interactive specs from their slots. > > Maybe it should be `call-interactively` that's turned into a generic > function (which would also open up the possibility to do more than just > compute the args to pass to the function, such as also printing the > return value or things like that), but that would be a more significant > change. > > While the performance of `call-interactively` and `interactive-form` are > not critical, `commandp` is a function that is occasionally used in > tight loops (typically when filtering completions from `obarray`) so > I refrained from making it into a generic function, and instead I make > it defer to `interactive-form` when we counter what looks like an OClosure. > > That keeps the common code as fast as before, tho it makes `commandp` > slow(ish) when applied to interactive OClosures. > > Making `commandp` into a generic function would apparently slow down > a loop like > > (mapatoms (lambda (s) (if (commandp s) (cl-incf count)))) > > by a factor around 2x or 3x, which is not the end of the world but > doesn't seem justified. > > The patch below also includes a use of this new generic function by > moving the interactive spec of kmacros from the kmacro objects > themselves to the generic function. The gain is that each `kmacro` is > now 1 word smaller (negligible, in the grand scheme of things, but > I included it for illustration and testing purposes). > > Any commment? Objection? My comment is that when you introduced OClosures, you never said that the plan was to go over every place in Emacs where they can be used and reimplement those places based on OClosures. It sounds like this is what's happening, and next we will see another round of churn of the code we old-timers are familiar with to make it utterly unfamiliar and dependent on stuff that needs to be carefully studied before it can even be understood? Including basic internals such as interactive-form and its ilk? All that to solve some minor issues with nadvice, which itself is a minor feature as Emacs features go? Doesn't that sound excessive? I'm okay with having OClosures, yet another new feature of Emacs Lisp, but I don't think I like seeing stuff like interactive-form rewritten to be generics or having OClosures in general permeate our internals. And speed is only one (important) aspect of that: I'd also like to keep those internals easier understandable by people like myself, who aren't and will never be CS professionals with special interest in functional languages. If that means bug#51695 must be solved some other way, or even remain unsolved, I think I'd prefer that if this is the price. I'm sorry to sound like keeping progress from happening, but it lately becomes more and more hard to do Emacs maintenance due to excessive use of new features whose tricky and hard-to-debug code makes finding the reasons for problems harder and harder. We already have areas where no one can suggest safe solutions for problems. Do we really want those areas to grow and multiply? IMNSHO, Emacs is not a platform for programming language development, it is mainly a platform for writing useful applications. Let's not go overboard with new Lisp features in a way that makes our main task harder than it has to be.