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.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Sun, 12 Nov 2023 10:44:59 +0200 Message-ID: <83fs1buzqs.fsf@gnu.org> References: <12da6bcb-1818-7fbe-12af-8d4607724332@gutov.dev> <87il6bt4z0.fsf@yahoo.com> <8734xetjkk.fsf@yahoo.com> <87cywhsrcf.fsf@yahoo.com> <87cywgx1z0.fsf@web.de> <83wmuowwp3.fsf@gnu.org> <8334xcwank.fsf@gnu.org> <83ttpsuiv4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18511"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joaotavora@gmail.com, michael_heerdegen@web.de, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 12 09:46:21 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 1r266m-0004e9-S7 for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Nov 2023 09:46:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r265z-0003Yn-BP; Sun, 12 Nov 2023 03:45:31 -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 1r265x-0003Yd-QU for emacs-devel@gnu.org; Sun, 12 Nov 2023 03:45:29 -0500 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 1r265w-0005RD-Gi; Sun, 12 Nov 2023 03:45:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=00NV0F8hBc8axXp8Cp8x8CFoEATW8iN9ttFG5Y3NO4w=; b=CvGyNoRYAPkVWppp5A1e W/GREyAN0pD8e++rbW0VxBDIZtVXrKcSbET+lpW7wnH9GP4X/PZLpIqzWd6G0Tth7KwvEIeGEeL8y etGUckMqfoX96zYp1jSimaVszGEazCmsO2zw8CNjnIVX/U+ad5YjRcI2jBJG7bQZz8u7sC1NRBSuu u8e05XlCeylA8iSb3JEP2MwwJc8XHRDfcbnV2AVQ7qRSCCZ6zQE74fwdfx1Rgd9CTX3YbdCZhot4i GjsxWkC5WCTRq99jdwIleJKr1SXGrMXa2ecMJWTEBg3BdHlqQjpWcYGvkIeEI6mv0VRAq4p8DR6kQ Iy0TFo2qIrgfAw==; In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sun, 12 Nov 2023 07:59:13 +0100) 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:312646 Archived-At: > From: Gerd Möllmann > Cc: joaotavora@gmail.com, michael_heerdegen@web.de, emacs-devel@gnu.org > Date: Sun, 12 Nov 2023 07:59:13 +0100 > > Eli Zaretskii writes: > > >> Seq is 10 years in Emacs > > > > It is preloaded only since a little more than a year ago. > > You're saying that the real promotion of seq is only a year old? Yes. > And that things will "improve" once the promotion picks up speed? No. I'm saying that we are still very far from a point where we have enough data to decide whether that year-old decision was wrong or not. Whether we see an improvement or not, time will say. > >> its polymorphism is unused in the tree. > > > > Searching for seq-* in the tree brings more than 590 hits in more than > > 170 Lisp files. > > And? The polymorphism isn't used. Then I guess I don't understand what you mean by "polymorphism". > >> Joao showed that it's slow. > > > > No, he didn't. > > Aha. No, really. What he showed is that seq.el is in most (though not all) cases _slower_ than the corresponding cl-lib functions. Sometimes much slower, sometimes slightly slower (and in at least one case faster). But that doesn't mean seq.el is "slow", enough to make its use nonsensical. Because why should we care that some call takes 2 usec instead of just 0.5 usec? both are negligible. The difference will only become visible if someone needs to call these in a very tight loop with a very large number of iterations. IOW, "slower" is not the same as "slow". If we cared about "slow", we would have implemented everything in C. We didn't because we have "other considerations", which are important to us and outweigh "slow" when "slow" is "fast enough". Exactly like in the case of seq.el vs cl-lib. Those "other considerations" in the latter case were abundantly described and explained up-thread, so I'm sure you know what they are, even though you disagree. > I've lost hope to hear something concrete a while ago. Same here, sadly.