From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Fri, 10 Nov 2023 08:05:57 +0100 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="31414"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Alan Mackenzie , Dmitry Gutov , =?utf-8?Q?Bj=C3=B6rn?= Bidar , emacs-devel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 10 08:07:07 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 1r1Lbd-0007xJ-T3 for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Nov 2023 08:07:06 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1Laf-0003fC-3p; Fri, 10 Nov 2023 02:06:05 -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 1r1Lad-0003f3-LZ for emacs-devel@gnu.org; Fri, 10 Nov 2023 02:06:03 -0500 Original-Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r1Lab-00024g-Ky for emacs-devel@gnu.org; Fri, 10 Nov 2023 02:06:03 -0500 Original-Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-53e70b0a218so2783085a12.2 for ; Thu, 09 Nov 2023 23:06:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699599959; x=1700204759; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Sn5OeINbDFW5EuY1c26MT6iRh2cmTbxrzzIBHGznXLo=; b=M6vU5BUE4aqFT4l3xlEb4iwvYhwgHuZhFf/oB6AbIP1J8ckAj5HzXnqxT8g0l169oE e9PWUaPQPT9AaTquCLqcRotDhe09apc0p/dCnMcYF33lTnauIPOoLzFYd4upbOYrgEx2 hwmh9JaFaFsywWlZ5NZGAaOZ6UIeicmLbkvzVDAg3E3OWPUgC1DRO9CLSSqka4e2emUm SJ69wuoiHJppAFzgzYneovZhtBejWu6o+yEv4i4K/EYv0MS2U0bIn7K0t8BdgvF1quSJ dhLX4wJ4iZMH9bGlCqE0ACg1aiptw1HlGvFkfIzYr27ppkVf4b74iLuXSxXSZevdO4IY FYZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699599959; x=1700204759; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Sn5OeINbDFW5EuY1c26MT6iRh2cmTbxrzzIBHGznXLo=; b=mnaKZDlP8mmBb8JzsQa7pIhleRLYLzbpIxe57tFoBiGy8kW1uRYsP2Uo4AWintFV5e Gw0ZHdw+rtg5SagVkf+pMR9PFYsErV6GmBpkhxWyOOgBz1LZzCYRRZvjIycP8SVGT7t/ 34GShWakLVuFurp+biWfbwUSUR7aqG4yGkLz1XORa74t/zPRf8M5uhQH5HMy6KI1i7u6 v60eWPH/sMWjljPBaf9AK1gnXWWVE/AURB7RZj2hrHQfqwCEoVjmRh3EkaaGeP/A4Lk6 lbP7GSFF1REeDSNrI9X9/D+UfhJRZqMMQQgZ4tOzrzkHpfNe04rJOVMYiJSeiaL1rKY5 PZUA== X-Gm-Message-State: AOJu0YzW9a9a3hN/6aiI1BREcs8oJvptlEg9yrL+YnAHNiCjdvbNXowX 3KEvlEM3tX0jebvjPOVKw7WRslJNKGs= X-Google-Smtp-Source: AGHT+IEfb64fSevR3rJaNTCIdDbCyH9qyTsM72YQEpGIM3/pRYu0LyzYjlNGDJkKHm46vvkMUbngdw== X-Received: by 2002:a50:d59b:0:b0:531:11fa:eacf with SMTP id v27-20020a50d59b000000b0053111faeacfmr6882753edi.2.1699599958644; Thu, 09 Nov 2023 23:05:58 -0800 (PST) Original-Received: from Pro.fritz.box (pd9e36b87.dip0.t-ipconnect.de. [217.227.107.135]) by smtp.gmail.com with ESMTPSA id w21-20020a50d795000000b0053de19620b9sm776389edi.2.2023.11.09.23.05.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Nov 2023 23:05:58 -0800 (PST) In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Thu, 9 Nov 2023 11:06:02 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::530; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x530.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:312460 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > 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 Thanks, that was well written, Jo=C3=A3o. I agree.