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: Sat, 11 Nov 2023 13:09:11 +0000 Message-ID: References: <871qd8sfdx.fsf@posteo.net> <838r7g8pys.fsf@gnu.org> <87bkcbrgnr.fsf@posteo.net> <25924.21015.19614.951576@orion.rgrjr.com> <87bkc4jpja.fsf@dataswamp.org> <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> 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="36954"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Michael Heerdegen , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 11 14:06:37 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 1r1nh7-0009Sw-KE for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 14:06:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1ngt-0007us-QK; Sat, 11 Nov 2023 08:06:23 -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 1r1ngs-0007ui-A7 for emacs-devel@gnu.org; Sat, 11 Nov 2023 08:06:22 -0500 Original-Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r1ngq-0006TD-Fo; Sat, 11 Nov 2023 08:06:22 -0500 Original-Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-507e85ebf50so3778837e87.1; Sat, 11 Nov 2023 05:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699707977; x=1700312777; 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=cySUcd/AWtQ1LaJjaXWRkGjvzhjR4FRSq8EZp2SFjf8=; b=lFW4HTiMoEE4LOk1/N/1Ypi8nLU8Q2f7I3ux7sBblRP9zJnjz4nVw3coN8tvjotH+6 NaQqTS7Ysq8cTgKl34wKBXke9cnWR6Ae1PtCKF/8Q6T1HEmUelP9CPMKCb+UIEwz9FOu ATue4/NaGat74USTmi14OMFAkFEH2ITcnQEPs4zwnZCNyMaYQv4hqLZD2USmYAEbaLc5 brnvBvsmIuQm4ogeRbIUhytVr4Tnt3p9Be+hJ9sEwr41N+QF3M7WOi3gCmergEYfaQE8 Z8lWowtsLCam7XyGTPtTQgYSJm8HBMCwsDYpMvL80sN2dhWifr1FYBT7w1FsK+hlyfz/ 2xLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699707977; x=1700312777; 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=cySUcd/AWtQ1LaJjaXWRkGjvzhjR4FRSq8EZp2SFjf8=; b=rsTN1CdDe+GviDiG+BjYwjxswMYI4j33hSNOHd2yjZD3HpqesFtUssXETOClSZEkIF q+GqlyE3LRNk72z/eU6llEWW8kPiF7DQ4yDwSsWim/pBi5UvoAcHiABy0N5C31jLk2E6 YrEkQRFbm77Mybrax/gYbThAHd1+x9S4gxlKv9/Gd5SUxfCPxm4ZedJG8Tj0V05R7XIk mXKbyjJ2rDPiOgkSSc9vu84W9Gb+ZbQo2lSctqTpChAHiV070Muvr7XmlIaIiLZ9+R1O 6c+Qi91mzuQt86ifFBGIZNwiHCYIBTtmfpGnifMCkvuzp2Ibt8+pz0f9F8Bd9x2pgO44 AKPg== X-Gm-Message-State: AOJu0Yxa73FfNVq47d/N1ZgEIU7jTant7RF+k7/6szYmKKFYadI/t94g 0iIR1CeWSq+iEdMNRYXKg87c23m/DK230GLgGtBTDkdGK1lS8g== X-Google-Smtp-Source: AGHT+IFTNmaEuMXxQkeHZ+OU6nK3L7SrWC4VJQZtIZemBEfUab8GwRACh01UA5wUiyot7sZwUCspyXI+35NRCr8/W68= X-Received: by 2002:ac2:4852:0:b0:509:8a68:eb8b with SMTP id 18-20020ac24852000000b005098a68eb8bmr1036072lfy.2.1699707977417; Sat, 11 Nov 2023 05:06:17 -0800 (PST) In-Reply-To: <83wmuowwp3.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::12a; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x12a.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:312552 Archived-At: On Sat, Nov 11, 2023 at 7:56=E2=80=AFAM Eli Zaretskii wrote: > > > From: Michael Heerdegen > > Date: Sat, 11 Nov 2023 07:01:39 +0100 > > > > My goal would be like this: > > > > - keep cl-lib available to it's current extent for end users > > > > - try to get unnecessary cl-lib uses out of the code base > > > > - make useful cl ideas available in the core language > > These are exactly our goals. We've been doing this for years: that's > how stuff like 'when', 'unless', 'push', 'pop', and others got into > the core. > > IOW, the way to make some cl-lib functionality freely available in > core is to have a similar or identical implementation in the likes of > subr.el or seq.el, using our naming convention instead of cl-FOO. I generally agree with the goal of bringing in cl-lib.el ideas into core, but it must be said here that seq.el, despite being a sequence processing library, should NOT be viewed as a drop-in replacement for cl-lib.el counterparts seq.el strength over cl-lib.el is that it is a generic sequence processing library. IMO it _should_ be used if there is the suspicion that the sequences being in that data being processed by a given function can be custom seq.el sequences. Or when there is good reason to suspect that one they might be such custom sequences. I think that seq.el _should_ be used in those situations because it expresses exactly this fact, so it becomes self-documenting. I think the argument that Gerd is making in his economic contributions is that very often seq.el is overkill. For example, in its current form should _not_ be used when there is certainty that the sequences are Lisp listsm because as I showed elsewhere here, seq-some is significantly slower than cl-some and cl-loop when processing lots of small lists. Also, I know you don't like cl-loop but in terms of efficiency it's sometimes a very good choice. For example, processing maintain list in order without it often requires a nreverse at the end or even more code. And the fact that cl-loop doesn't need to do dispatching on different sequence types means it's faster. And less polymorphic of course, but sometimes you simply don't _need_ polymorphism. I do agree fully that writing (cl-loop for i in l do (foo i)) is kind of uncalled _in any situation_ if you can just write (dolist (i l) (foo j)) But when you need to process plists, for example, it becomes very handy. This construct, which does require knowing a bit of the mini-language that is cl-loop, (cl-loop for (k v) on plist by #'cddr collect (cons k v)) is still the most concise way IMHO of processing a plist for example. Of course that is debatable. Maybe you prefer a raw while loop with some auxiliary variables, but while that is more universal, it doesn't necessarily mean it's more readable. These are two different things that people are mixing in here. I would be on the fence if this example would justify introducing cl-lib.el into a file or not. Depends on how often this plist-processing business is needed. Or whether there is a pair-sequence-processing util in seq.el AND performance is not at stake. And certainly we should not immediately shoot down a contribution to the core without "batting an eyelid", as someone suggested here, just because it doesn't fit a stylistic preference. By the way, I also think Michael's idea of splitting up cl-lib.el further into smaller bits is very good. Jo=C3=A3o