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: Thu, 9 Nov 2023 11:06:02 +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> 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="23329"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , =?UTF-8?B?QmrDtnJuIEJpZGFy?= , emacs-devel To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 09 12:07:25 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 1r12se-0005op-P0 for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Nov 2023 12:07:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r12rd-0001Qu-F1; Thu, 09 Nov 2023 06:06:21 -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 1r12rb-0001PR-H6 for emacs-devel@gnu.org; Thu, 09 Nov 2023 06:06:19 -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 1r12rZ-000768-Mt for emacs-devel@gnu.org; Thu, 09 Nov 2023 06:06:19 -0500 Original-Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-507975d34e8so993239e87.1 for ; Thu, 09 Nov 2023 03:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699527975; x=1700132775; 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=uBF/oajU1sGRB1m+fprFOr47ig26qVHGjWv9IIcLcAA=; b=KWpx1oOhsWVMnkLmyqCigHzWZRsUi/ifttylkQGEvgZbBCWtX/PeoG26zz2JTh6Kte kPh60tZydF7MDi2Myz35wTPQlGmEi/C0uV7WuBEQl8DuXvkN4EhgVBOYo2Qm/+QYqYw6 oXsWciGrXuqtSp9A+peTGG6NCUQ80O+K5lD+WrY4+hRJLhda9zQkCIsO65erpAhZ6b/L 6Q9TaM2gDlOPOyunbREI38Ks/yfnk0pzur0bp+FAWogjtC3eVB1AeU46wfdAGXDOqe5y uZ8GMDZ79ioaWES8sxEgukXQOlK2Haw6tj0MSVsNfwiR1mNbrA73FHgZPrPnEulFFUKr 04YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699527975; x=1700132775; 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=uBF/oajU1sGRB1m+fprFOr47ig26qVHGjWv9IIcLcAA=; b=wl2b1VKgBSZ/GnWl+HvGrqywTdS5apm6SFHopCnwoWLWrjvlKZoHh2L8mapZgHqCcR DjwAkANBA2Zf8NXRoXVRcGRQGof+HHQkRhf/mwmdB7ZsJkMNNLrlffLfi3EOeQiqAqSm R3rA+nQ5SpATdGv6qca8KYc2C9aiE1NkfC+PSkZe47+2lqQZeyClQrN/avTdCXmRFDhK nFLdFEzQmea3mECjW30Sil524W5mu6OV1REZA4BhoTunQghkBjz6/ocCS07OJqjIsuUy +K2P764r2mFFCHbsIjTUdm/2+qWleTSsnemgtkGCHqick7i4Wdq6oCvRylvnjC17Bc9a 2hPA== X-Gm-Message-State: AOJu0YwpuZXxGSXyfQ/prnYBi/0l7KNzIhZt++L+2yNEgwWMCYccLNoV gvtynhbiYLno9XCLhYyT5uVcOVOjq4K2lttTNBnBRpyRvxdbAg== X-Google-Smtp-Source: AGHT+IFU03Hf56kFalLomHPsuLrZcYdLzxFTEDRBCH78tzZte265iRI2h7quDDYOLB1QJAQia9me75sUe9KigO2joKA= X-Received: by 2002:a19:e007:0:b0:507:b935:9f5f with SMTP id x7-20020a19e007000000b00507b9359f5fmr1049791lfg.24.1699527975094; Thu, 09 Nov 2023 03:06:15 -0800 (PST) In-Reply-To: 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, URI_DOTEDU=0.001 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:312396 Archived-At: On Thu, Nov 9, 2023 at 10:05=E2=80=AFAM Alan Mackenzie wrote: > > If it needed any confirmation, I too like cl-lib and I too help > > maintain other people's code in the Emacs core tree as well as > > maintaining a number of libraries I have authored. > > There's a difference between liking cl-lib and advocating its > indiscriminate use. I don't think you've done the latter in this (and > related) threads. Yes, you're right. Indeed I don't' advocate for its indiscriminate use, just as I don't advocate for indiscriminate use of anything, except perhaps drinking water and brushing teeth. > Nobody who likes cl-lib has yet addressed the point made by Richard and > (less eloquently) by me, namely that the incorporation and use of cl-lib > swells the size and complexity of Emacs Lisp to the point of making > maintenance difficult. What is your view on this important point? That it doesn't make maintenance any more difficult than any other Elisp construct, be it very old and curiously named like 'rplacd' or much, much newer like `seq-do` or `pcase-lambda`. My specific view on cl-lib.el is that it brings us a small part of the results of non-trivial design work put in when important figures in the Lisp world met regularly for many years to deliver what has proved to become excellent, battle-tested, widely understood and impeccably documented programming abstractions. What I'm reading so far in this long discussion is that the argument of its detractors isn't really that cl-lib isn't good, but that it is superfluous and that learning it is a burden on maintainers. Well, it's just as superfluous as all of Elisp apart from two handfuls of primitives, I guess. Or any programming language for that matter, if you know enough machine code. Or any other programming abstraction I happen not to be familiar with. Also I seem to hear that Elisp has some kind of ideal hard-to-define identity or fingerprint and that it shouldn't try to become anything else. But this argument is very strange given Elisp is, like any decent language, easy to extend. Not to mention I struggle to see the technical advantage in uniqueness for uniqueness sake. A good part of Elisp is about a special purpose function: editing buffers, and an the equally important part is about doing things with bits in memory, there's no reason to advocate for singularity here. I also hear Elisp shouldn't become Common Lisp, but not only is the use of cl-lib.el nowhere a step in that direction, but also -- somewhat ironically -- if Elisp _were_ Common Lisp, then that hard-to-define identity would be much easier to define and language extension would be much easier to organize into compartments to facilitate policy-making. Again, the only thing that has brought Elisp any closer to Common Lisp significantly, was the introduction of lexical binding some 10 years ago. Elisp looks a lot different now than it did in the 90's. Closures everywhere, higher-order functions! Shudder! There's even talk of a continuation-passing style library, to be called future.el or promise.el or something. Oh dear, what will be of us that we will have to evolve like any other language in the world! So I propose we let programmers use their judgement. Really respect people who write code for no money and give the copyright away to the FSF. Maybe suggest guidelines such as not introduce cl-loop where a dolist would do the job just as economically and elegantly. Don't use higher-order functions just because it looks cool. But maybe do suggest to use cl-position with a :key and a :test instead of a complex while loop with an auxiliary variable. Or cl-set-difference instead of nested loops. Suggest to express intent, use abstractions. Suggest to be consistent, be scrutinous, be "discriminate", be mindful of the style of the current area you are working on. But don't suggest anything too hard, especially if it's not modifying code you have authored. Don't use arguments of authority when you can point to specific things. Be generally respectful of people putting in any good work even if you don't like the style, and try to learn a new thing or two every now and then. BTW here are some nice generic suggestions from the Lisp world, written by two fenomenal programmers. I love reading this from time to time: https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf Jo=C3=A3o