From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Thu, 09 Nov 2023 21:45:55 +0800 Message-ID: <87il6bt4z0.fsf@yahoo.com> 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="4842"; 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 Thu Nov 09 14:54:40 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 1r15UW-00011Z-2i for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Nov 2023 14:54:40 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r15NQ-00080O-PJ; Thu, 09 Nov 2023 08:47:20 -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 1r15ML-0006e5-RS for emacs-devel@gnu.org; Thu, 09 Nov 2023 08:46:14 -0500 Original-Received: from sonic309-20.consmr.mail.ne1.yahoo.com ([66.163.184.146]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r15MI-0001sW-MQ for emacs-devel@gnu.org; Thu, 09 Nov 2023 08:46:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1699537567; bh=mqvMcU83AhZEK7lX86ecCYgjxB75O/+c0In63JWZhqE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=o4koz9+Ptd3EGkHC4QkNr+L3c/eoJdUuEjXbDurUCfi2F3pCrTxXSlS9lTSOcGZP3QutY88KT5H1IUb603QfOiCqlBgdOZmiPksGxUE64QeOIwhCxgssL3GEa732vTt8ABzxrHd+Qth7ypTgsRn4vBf/8g4ECanf3G9b3rh5XRD33gl/vkv0V2L6lQ0SRuSWZquo4szG3RL5I/CkskBsp8SGQUfjLk/ZghAb5bU4KqnirrfsbuxSPLYykxHy/bcjZmUjRgBm6/4+JD09Bmp1XEnGrQIyQTXMsnFo/9a5HF2r+DH5Cc2RuLj4zJYN1egP9bCzDkZQu0XTZ0RvFWQrGw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1699537567; bh=hEb6DCHfHdGOVwXknA0oGKV1l+EnlzDh1LcH9MFAWox=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=es/Lwat2+8sZlKfWGt0ZTXvhof4ESeLPBrK/EJfR/0g1uGE+9iYMRua9CPqEYAbZ3XfHEgkorHnalBH/8xdZQR6HOPKp2ysEJfscPz6Cem+yw4P90iWv9AtGJtPSzVcSqTMB6Fgz/MG5VMP6cAzGuHEJgl4omfStKFUI79nL6g4QiZpsjyCJ2oOyaoquKyYzU1JSGekQuQ5bF4pcUCaQUcTgI666RKJWYyhSzEcbFNEPmfZ7KK1orr5AHT+jWt95P0McDtJh37K8Y6MipweelYL3iffK8xImFC7B1b6XqVbmg48XI9auXj8TvIUVqxfo8eZIdcOieVZSaxKRSH7pLQ== X-YMail-OSG: uoHYFmEVM1ksPmMC81cKkeVnyY9PueLFY22nCHEZm7ZPVsfHUXt6RKOw4Cxdmry vqqNX1UmeHSytmK3bb8NL2mi2evNCwDocuWM9WegMfLreG.kINlQXsQgA1ezwrVR9xRqL605DuyA Xm8l0VSzrBsL_qF3DJxIVzD6mx5pSXMlpQfISXn0ol3d5DI_B9xIWzGYTeAeZPUDAYfZhs5BCerx cRUIBNT7jti5wEqSJoL4bQW0B0HnoFoD.LCPCi9eFDNy1i.pQPkdYxStEtgGEykcB2FQ7OBjh8Gv 3ATG6PdwyoiowjBWGMjaWfS815QFIlUyRdxHaxuF98aaiaG2N3AJpstxHDVNUrG_mx.w.J9cKHmq Q11MlETuSTo5cx4c9UzjnIhCyfhyYsdGchRcfFHLsbp28lS4vTW0mnTWNEekOL_C3NtFeCVxJnck eGdZqcexGP2wz5RbE2nTWA7mUG2kIFp41kqLpV9aujSadzIwx1w7hyPh7xLOBmvXz8djkd25tovY oAdMB1r8gAIiOLKgVqsZBdSc9b9OF_ttFfuqh_hSGfhBcwpnLUJkdUbl6ZN_669eQFNcvdeiWZ9d PUYOJSmcYbISGyr_FUTIFZVjF7TmX8dGSzX6iTzJCm24Zs_F00g8jPmE3oRAcyimZWCOq9Ksqfid PdMwfZmXwToXfB5rqrwFXeCUSMvQUFVLYJ2FnpslspVbERpflCWr9eL_toH19mhIrXYpUCwQYuuu .AOvaSIdTo8Fhuntm0vqGfHBlny6wkmUuLX11xcNqajQOHegLUKqZEagbCp8s9kBKuwiUm00pe04 zHHOgBS8fWAs0BDwp8PyEvWUC9ptpRy3fsDxI08Dsh X-Sonic-MF: X-Sonic-ID: 69c53d28-ce36-4843-8b59-dbbdd7e1e212 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Thu, 9 Nov 2023 13:46:07 +0000 Original-Received: by hermes--production-sg3-8696d769c6-r64c6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0972bef4d14d5d0202fae1840025b7ec; Thu, 09 Nov 2023 13:46:01 +0000 (UTC) In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Thu, 9 Nov 2023 11:06:02 +0000") X-Mailer: WebService/1.1.21896 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.184.146; envelope-from=luangruo@yahoo.com; helo=sonic309-20.consmr.mail.ne1.yahoo.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, RCVD_IN_MSPIKE_H2=-0.001, 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:312410 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > 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. Such casuistry and non-sequiturs are the reasons I'm glad I have thus far given this conversation a generously wide berth. But one's restraint has its limits, and I suppose mine have been overstepped, since I can't keep myself from delving head-first into this madhouse. Here goes... > 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. cl-lib does certainly provide some value for money, by way of constructs that lend themselves to many general situations, but it does not provide this value in the lion's share of the circumstances these constructs are used in. Consider the blithe misapplication of CL generics throughout the window system code: (cl-defmethod gui-backend-set-selection (type value &context (window-system andro= id)) ;; First, try to turn value into a string. ;; Don't set anything if that did not work. (when-let ((string (android-encode-select-string value))) (cond ((eq type 'CLIPBOARD) (android-set-clipboard string)) ((eq type 'PRIMARY) (setq android-primary-selection string)) ((eq type 'SECONDARY) (setq android-secondary-selection string))))) do we really expect window-system to be anything _but_ android, so long as a window system has been initialized, when android-win.el is loaded? Why was it necessary to convolute the code when g-b-s-s (and its ilk) could as easily have been defined as an ordinary function in each of the window system files? For a second example, how about cl-list*? Is there really a purpose for this function, in light of how it can always be replaced by: (nconc (list a b) c) and demands callers load cl-lib.el? The call to this function in desktop.el is particularly dubitable: as far as the eye can see, it is the singular reason that file requires cl-lib, its remainder being implemented with the cut and dry Emacs Lisp builtins that are well known to us all. This abject misuse of cl-lib extensions, not an unqualified opposition to extending Emacs Lisp, is the catalyst of most misgivings towards it. Like begets like, even imitations of like: as the corpus of files which load cl-lib for legitimate purposes burgeons, so does that of files which load it for positively frivolous reasons. Thus usage of cl-lib should be discouraged in general, and users firmly exhorted to seek replacements. Even if there are situations where it is not superfluous, their existence doesn't outweigh the proliferation of that where it is, and ultimately it stands us in better stead to treat it as such in general. > 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`. pcase-lambda and seq-do (plus the boatload of seq and pcase functions) are not "other Elisp constructs," not in my book. seq functions are all generic functions, and their documentation is nothing short of inscrutable; take the example of seq-do's: Apply FUNCTION to each element of SEQUENCE. Presumably, FUNCTION has useful side effects. Return SEQUENCE. What is a useful side effect? Does this imply FUNCTION can modify SEQUENCE as it is being iterated through? and each time I read the documentation for pcase, I wind up bewildered by the needlessly laconic style it is written in. Most of its users don't display a persuasive need for it either, a demographic of which frameset.el is representative: much of its work is also replicated in the *fns.c files and frame.c, which seem to fare equally well, despite being authored in a language that largely enjoys an absence of byzantine constructs. If doc strings are meant to be incomprehensible without recourse to the Lisp reference manual, then I suggest they not be written at all. A doc string that alludes to and accentuates concepts such as "useful side effects" without providing the reader with a definition or a reference as to where he can obtain such a definition is not edifying; it leaves an unpleasant vacuum in the reader's mind that rankles until he bows to fate and reads the manual anyway. rplacd and rplaca are aliases to setcar and setcdr; Emacs Lisp code ought to use the latter, and aliases and the wholesale introduction of functions from other languages are plainly incommensurable. > 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. It's a fair bet that Common Lisp users today number fewer than Emacs users; of course this does not immediately reflect on the character of features present in Common Lisp, but it is a consideration to bear in mind. The quality of the documentation, which for cl-lib is far from irreproachable, cannot allay the challenge posed by learning to read and write a language that is in plenty of respects at variance with the language Emacs users and developers have learned. When the latter is in fact documented beyond reproach (save for rough spots such as the said pcase), more than adequate for programming in Emacs, and understood by all Emacs users, the profundity of the deliberations underlying the design of Common Lisp and the eminence of its designers are not justifications for its pervading Emacs code, let alone to the degree that it has by now. > 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. The relative ease of extension implies that we should be more circumspect in judging which extensions to allow--that is the basis of much of the argumentation here, not the unsupportable notion that there is an identity to Emacs Lisp which must be preserved at all costs. > 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. This is self-evidently wooden language. I expect the likes of "compartmentalizing a program for policy-making" from suits, not from free software developers. > 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! This is not ipso facto a net positive and is also beside the point. > 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! I certainly hope never to see the day that becomes widespread in Emacs code. > 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. Respect for volunteers is no doubt laudable, but it is very much an position to be considered alone which everything you've presented above does not impact and nobody takes exception to. From it, and even supposing for the sake of argument that everything else you've said is incontrovertible fact, it doesn't really follow that we should not seek to reduce the incidence of cl-lib usage in core code. Now I can't be certain that is the object of your militating, if you will, though promoting cl-set-difference and cl-position as alternatives to hallowed Emacs Lisp constructs does suggest so, but the principle argument against these constructs is that they are alien to the small group of individuals charged with trudging through code where people want to make use of them. So no contentions resting on their virtues and distinctions rather than their prevalence among us can hold water...