From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Fri, 10 Nov 2023 13:16:57 +0000 Message-ID: References: <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: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13400"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , =?iso-8859-1?Q?Bj=F6rn?= Bidar , emacs-devel To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 10 14:17:51 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 1r1ROR-0003Il-Ld for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Nov 2023 14:17:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1RNy-0000P8-Co; Fri, 10 Nov 2023 08:17: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 1r1RNg-0000MF-2i for emacs-devel@gnu.org; Fri, 10 Nov 2023 08:17:04 -0500 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1RNd-0000mf-5x for emacs-devel@gnu.org; Fri, 10 Nov 2023 08:17:03 -0500 Original-Received: (qmail 11116 invoked by uid 3782); 10 Nov 2023 14:16:58 +0100 Original-Received: from acm.muc.de (p4fe158a9.dip0.t-ipconnect.de [79.225.88.169]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 10 Nov 2023 14:16:57 +0100 Original-Received: (qmail 21448 invoked by uid 1000); 10 Nov 2023 13:16:57 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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:312485 Archived-At: Hello, João. On Thu, Nov 09, 2023 at 11:06:02 +0000, João Távora wrote: > On Thu, Nov 9, 2023 at 10:05 AM 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`. OK, thanks for answering the question. Please bare in mind that other people's experience of maintaining code using cl-* is very different. > 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. No, it's completely superfluous, even if it can be convenient. Learning it is a burden because its objects and abstractions are, well, very abstract as well as being badly documented. They have little relationship to anything concrete in Emacs, and they are typically complicated with many seemingly random details in a way that Emacs primitives are not. > 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. I am familiar with machine code. It is perhaps pertinent to remark that modern processors tend to the reduced instruction set model - that the complicated "do it in one single complicated instruction" notion doesn't help the writing of good compilers, or the running of programs efficiently. I suspect that analagous logic applies to programming languages too. [ .... ] > João -- Alan Mackenzie (Nuremberg, Germany).