From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Wed, 15 Nov 2023 15:02:15 +0000 Message-ID: References: <8334xcwank.fsf@gnu.org> <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" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27834"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?UTF-8?Q?Gerd_M=C3=B6llmann?= , Eli Zaretskii , michael_heerdegen@web.de, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 15 16:03:26 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 1r3HQL-0006u9-Vx for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Nov 2023 16:03:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3HPV-0003MH-S1; Wed, 15 Nov 2023 10:02:33 -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 1r3HPU-0003M3-PN for emacs-devel@gnu.org; Wed, 15 Nov 2023 10:02:32 -0500 Original-Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r3HPR-0007yB-UT; Wed, 15 Nov 2023 10:02:32 -0500 Original-Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-507be298d2aso9200754e87.1; Wed, 15 Nov 2023 07:02:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700060548; x=1700665348; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+CS/Aao3Ubb5CfrRVwCWLMDmpDPkM0qV6Z+Vkj/TrQ4=; b=VIuVoORNUIWaet1ZkMjuOPjKZAEXFOnNnIoMcvFhhbkl6FFZuKKQuU6U0VUY2ycnmN jftDY1+tojFr8ThMhVPDba/rboABbv344HQwq4+MixtQUVdOYu5KTo/HpKz/QTOblv2S 0Y2/0/nbdDQsG3HPpx9PCEMRIOpCU2Rkr2ZAywjsoQ9KWrlmPV64m/kMKg67L0OB81Bm gCGlj2eQr4s1etmdLJ5jCWoEvANBNAw/u9zZdZuyQ+NCrqRi/NbQH294KHHDAp/19J/t 5LDiYSbhKZJwskIdSXRz2QdjTnZ36oAi5o1NYYPf+E9CzCkjrwbSKFfVGjUHbimZXKfq 70wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700060548; x=1700665348; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+CS/Aao3Ubb5CfrRVwCWLMDmpDPkM0qV6Z+Vkj/TrQ4=; b=LKXFqiWe3y+FmIdY/zsNQnnRYD3EUSpOmtYQAo/LRna65JtF+4cy5TPzn8eqU2tPjN i8nH9T+LEXzz/q6Ym6zdkwSt0uzxmtLJ/p7r0cV+OIC3Lxq0xSovxwSiaLl03Kv8qEE+ X/RGiQ/hchkuUbbUELfQnD7QJxUIuWd176ZwLXg40ncWtSmId9Wl+UfS2YuvuuCR2oEt I/Lon2WpBjz05FbECZnCy0RgWbYMEu/eLY0tpBDk7jolUbuZze3hHGUlfPa3trBC5+It KArSiiMxz8SGmHJThBn5AXXdHyFRfIamTPHGAv2Fn/qoRUadnLaeX0ArcbQM259T9Qsy ZIEg== X-Gm-Message-State: AOJu0YwVwDITXCkR6byYY3q3odca+DkhCnRoCPZsoUkUjbEfFDKDkQLr hZGIdvWLgnyj4VbJM/Gdi4z1kChPrpIEtJRfPbw= X-Google-Smtp-Source: AGHT+IGNGQg63hHrQrRjdqoauFTMNGAxM8Pp0Rsc8Na73w3b4+d+maNp9+WVN8tKdil0mupV2I99qIq3+Ztfi7GpS+c= X-Received: by 2002:a19:2d1e:0:b0:507:a40e:d8bf with SMTP id k30-20020a192d1e000000b00507a40ed8bfmr8414503lfj.7.1700060547336; Wed, 15 Nov 2023 07:02:27 -0800 (PST) In-Reply-To: <22e4cb4d-a8f3-1530-881d-b8c59c5d969b@gutov.dev> Received-SPF: pass client-ip=2a00:1450:4864:20::12b; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x12b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:312766 Archived-At: On Wed, Nov 15, 2023 at 2:05=E2=80=AFPM Dmitry Gutov wro= te: > > On 15/11/2023 14:14, Jo=C3=A3o T=C3=A1vora wrote: > >>> But say I did that seq-do, then what is the seq-contains-p generic go= od > >>> 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. > The gains seem > consistent, even if they don't extend as much to certain scenarios, like > custom test-fn. In that particular corner, both your (the library dev's) optimisations and the user optimisations are tanked, yes. > 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. 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. > 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. 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??? 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. > 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 just shouldn't. 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. 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. Jo=C3=A3o