From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Wed, 15 Nov 2023 21:12:12 +0200 Message-ID: <339b58d6-5a44-8393-c2cd-4c935147dde3@gutov.dev> References: <320999cc-6c83-2315-0044-cc0403400af3@gutov.dev> <9ab5d2bd-a648-cae0-a4a7-ae86be10af0f@gutov.dev> <87r0kuqxbf.fsf@gmail.com> <54e115a2-fc36-3056-a030-0dbf32416ddb@gutov.dev> <43f290b0-4119-597b-c89a-0fb4c7db1665@gutov.dev> <1e7fe1ef-af7d-3222-7b9e-b569b3c97ccf@gutov.dev> <22e4cb4d-a8f3-1530-881d-b8c59c5d969b@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13347"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: =?UTF-8?Q?Gerd_M=c3=b6llmann?= , Eli Zaretskii , michael_heerdegen@web.de, emacs-devel@gnu.org To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 15 20:13:20 2023 Return-path: Envelope-to: ged-emacs-devel@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 1r3LK9-0003Ge-U0 for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Nov 2023 20:13:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3LJG-0005dm-Op; Wed, 15 Nov 2023 14:12:22 -0500 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 1r3LJE-0005dP-Pz for emacs-devel@gnu.org; Wed, 15 Nov 2023 14:12:20 -0500 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r3LJC-0003tf-ML; Wed, 15 Nov 2023 14:12:20 -0500 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5A4915C0067; Wed, 15 Nov 2023 14:12:17 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 15 Nov 2023 14:12:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1700075537; x=1700161937; bh=tJZnODtMniayhhU2B+hPdI/USyJGPVIDqxB PTEQRqbk=; b=mducjhVlJcGshlPDYMmoZB8rmmez1NA0ZvgOn7tQAHDF0GoKk4M GyJ3X5qXBOWc+/P6R5QGmOn55eqWqT1Tl16C7FfPp7n7U/+K6gGROj7Z1PVjb6B2 1TR3He3wK7NdJUOjZD/OEzI6MrqDPhDNtw4Q64qjErZXPtSyuOhA+jrHcFgc0ASR WZVzmIgnJdMM4UGyl+3PUPy5LErjCHE0/OLecqNkF148A6eSCit/VOC5aNf9Enc+ +jpSjlyRlEbFVKsSXy2jMpbzKmqHerXdyK8TRkw4RaNzHhReB/Fv1S7DXyrI4tsa e/IVQdDf4aODGR9niEmLFi70BqJz0YECXJA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700075537; x=1700161937; bh=tJZnODtMniayhhU2B+hPdI/USyJGPVIDqxB PTEQRqbk=; b=bpYBhIfA8g814RFKtcb8TXP5rxhv9cTcn74oyekqdlIQspD6hjN 8CcD3m3X4MOjgABOlqmdl9kWDuD1aJtEM1Lhnelupo5CwZJnNY4rqD1ShVmcbJ6d vhPXgXmqrElykd7olDC3QFmEmnO9KgXIKmrKf6Id1UDT9HtD3my9Hyn/L9WUq/O8 tcJaJ4/vW513u4vg7MmGA+K0AyrFINH1SVF4KxGNinwsPPupogVVxOfLjkccAIi0 JNuXhoGPen0YKlJN/rgpo3zpnHmCfE6SB8jfz57dbzkrQGD592HBPFuQi6SiOJCs g8MjbkfeoXLCqTKMPBSdS9VGAca1u/Yk+lA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudefiedgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffg feejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 15 Nov 2023 14:12:15 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=66.111.4.29; envelope-from=dmitry@gutov.dev; helo=out5-smtp.messagingengine.com X-Spam_score_int: -46 X-Spam_score: -4.7 X-Spam_bar: ---- X-Spam_report: (-4.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.895, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312769 Archived-At: On 15/11/2023 17:02, João Távora wrote: > On Wed, Nov 15, 2023 at 2:05 PM Dmitry Gutov wrote: >> >> On 15/11/2023 14:14, João Távora wrote: >>>>> But say I did that seq-do, then what is the seq-contains-p generic good >>>>> for then? Why some many redundant generics that the user learns the >>>>> hard way have to be consistent with each other? >>>> So any new type gets a lot of functions implemented very easily, and >>>> could add specialized implementations for performance. >>> Fair enough. Except, as you noted, those optimizations can be >>> completely nullified overnight, when trying to optimize something >>> else. >> >> I don't see where they would be "completely nullified". > > You wrote "tank" :-) I was talking about those kinds of optimisations, > not the ones you're making. What I meant is in order to optimize the > list/sequence/#equal/#eql/#eq case you tank the user's optimizations > to custom sequences. Only until the author of the third-party data type updates their code to include the method seq-contains-pred. And if that code is not inside Emacs, its time-to-market measures in days, not months or years. >> Even that one should be improved, though. > > The only way you are eventually going to get to equal performance > with cl-lib's fastest variants (but only the non-destructive, of course) > is if you start every seq.el entry point with sth like > > (if (sequence-p seq) (call-equivalent-cl-lib-version seq) ...) > > But then I don't see how that fits in with the cl-defgeneric, > which does dispatching before that if. The only way I see this > is to invent a new kind of specializer in cl-generic.el like > 'definitely-not-sequence'. There could be some other solution, > maybe Michael as a clue. > > Anyway we do it, it's much easier than trying to wrangle entry-point > by entry-point by adding more generics and finding pitfalls like this > one about seq-contains-p. And this I think, is what Michael is > suggesting: fair enough. I don't immediately see that new generics are needed. But if someone finds a workable approach (with hard numbers), good. > But of course we will be outlawing every extension like the :m6-sparse > example I gave. > > And also, IMHO, we end up with a much poorer protocol in terms > of versatility (no find-by-key :key, no :from-end, no :start/:end). > But this part is not about performance, rather interface, and that's > not the topic of this subthread. cl-lib is more flexible in one aspect (its additional keywords vocabulary which basically multiplies the provided interface by 100x), but it's more rigid in the data it works with. >> If that is the only drawback we can find, it is an unavoidable one. > > There is still the other example I gave you. I think your only > way out is to outlaw my :m6-sparse extension. You basically have > to outlaw everything (:around, :before, specializers) that > cl-defgeneric gives the user when it comes to the sequence types > for which you want to have acceptable performance. Could you try to explain what I should find in the second example? What do you mean by "outlaw"? Does causing worse performance for a short time constitute "outlawing" something? > And even outlaw more stuff. For example, these generics even have > specializers on all mandatory arguments? > > For example, why does seq-do have FUNCTION as a required argument??? Because FUNCTION is applied to SEQUENCE? > It should be &optional or a &key, with a default value. Which > cl-degeneric obviously supports. That way specializations on FUNCTION > become impossible, or at least become much harder and there's less > risk of tanking user code. Design mistake IMO. I'm reasonably sure nobody expects function to be anything but a straight function (symbol or a lambda), because that's how 'seq-do' is used throughout the code. >> But that is the price one has to pay for correcting a design mistake. >> We're not going to do this every Tuesday. > > Sure, but that price increases manyfold if we start suggesting > seq.el as a replacement for all your sequence processing needs. We can first fix the mistake and then go on to continue "suggesting it as a replacement". Or not. I don't exactly see it that way, though. And you give an impression of arguing for the opposite: toward never using it at all. > Why working on the :m6-sparse extension, I noticed Emacs becomes > noticeably slower, and I suspect that's because while I was editing, > all the seq functions I was writing where being probed for > applicability, while core things like completion, buffer-switching > etc are calling seq-foo generics. It could be helpful to do some profiling and see where the slowdown came from. Could it come exactly from the set operations? > I find this performance aspect very bad. Maybe it can be obviated, > but only if you drop the '(if (sequence-p seq)' bomb into seq.el > somehow. I don't see how we can avoid that one. I don't quite see the need. And it's unlikely to be of reliable help: my observations say that method dispatch simply becomes slower as soon as a generic function gets a second implementation. And that implementation might arrive from any third-party code.