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: Fri, 10 Nov 2023 08:31:55 +0800 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> 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="34498"; 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 01:33:35 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 1r1FSp-0008pB-6z for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Nov 2023 01:33:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1FRt-0004PI-N9; Thu, 09 Nov 2023 19:32:37 -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 1r1FRr-0004Or-Pp for emacs-devel@gnu.org; Thu, 09 Nov 2023 19:32:35 -0500 Original-Received: from sonic312-25.consmr.mail.ne1.yahoo.com ([66.163.191.206]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r1FRp-0003gP-KU for emacs-devel@gnu.org; Thu, 09 Nov 2023 19:32:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1699576350; bh=td6VyJ2AORD3RhaLVC9zgnX3DDT8NBc7z/p6CBCgmiQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=kK8HD2wycPXro/7o+PKmvaZfmbTW9yQaYWilUzyPszdn51zxtK0hqsWeHkvJxNG9dIgT1JjY5v8qGDjFPTR4RaGkQ3YR9FvauGudyniCuM2u7SQ3ZH92jLnx9zTdrGuldt4Mkw7DU1taW+ShTu4OsEibX8+M65QKQdbQWOp93N0xKA8ZMsJ7Zv1pjuEsA+rG3Uhf5BP4HswSmjGAxT4v9covCRzlt6qQ8b6O20UWKwIqQ8NWgBjNI3Ayt/CA5OrRdVK8VQCIAzwtCNKZF+Tcp5z8Qh65xWLdyvnZd1eMMXVamtYHT2/AZzThyul8s5JuKwPXQgdrT8FgkP8ibTWCAw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1699576350; bh=3xJlkoqi+QcZtr4OaYJT+55S5ylk9XMe+Pdy18DkXEf=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=InEDMnfRUiPNfB+4IOBGyksRoMWlicuZHiLwnus0Mko86aQqQmdHDqpJRom+97ekn+RZXdUGMIThVDBOxVNiIO+EG/Ob/FIp2xyY1klfJ5MDaXQRZd8C4S24ctvlQbbkmiLaU7jy5FWM9njbUFRdxkur1uE+16ZSm5HKG05jA9v5qKyyFACslksNxkamUcqhruzH/5P5+MnEEE+RoV/PpnHfKRwE0pUbksGYRZDxWCyPQMmT9ezWgUgC61d5GG4bStsOw7aFhNkZNCT4I6a1kZR+FvILmc4RhlUNl5ONxBMg0uXbemguDphct2Gg3HP8afh0jyU7wRDH6MrZMLQgDA== X-YMail-OSG: t44SOjkVM1lkTPH9AFu4yq6AwZsCfs4zkbLjMeWHdOaOcIdthy0jwKU6tt88uS2 1qBodHvoWuEFK0mptfiA64SCLisk4UgazaXWkGWzpfCGLl5zXS2LjkACISxb_U7SmHH.nSBD3OKl irQ_4dDSQSHeebBp.ruVeLo5LoTZ9venCh2p4RikNcUumYWe78jLyiW3fLLk_f2C4j35O1uERo0N N0ubQ.b3nINQXGb3vBrcu.7DT_x55bvv50ilJUWvVz8KD8MgvC7JCo4D0H1S41NkDVKQyV.nip_V sMcoKO8bWO56ycEm7.W4pXc0qIscRfRZBs7eNFI0ZXbKTxDhYTR6SYLgEN3BhrwFa0Ou9gq.nwl. qefQLn5IwIgzbLoK8IVJEALHPQdMmZF6KUnoFYDu_dXle_8W3RQNkg.cq3jFFqqF2K4uRHLU8yiw VwX1EQzdLz6oGmZbPn4xQqCWASogBOp_SR2d_N4ZLwugFPsgbBJudaSfNlH3iE4tbcZpRd_wx8iP ad9FwvSjiIV2lDWlExrEDaJ3qQZRXTyvv4QpIpzw5gRALGhu5IIpYMc1klXrvNtUiaGx_9Ma7YTf YZtFLtNbTwPrgDjJvsukeMIcpJcxsFatLUhvCU0TNDLkdQc.B9Q7oeFq99ol39CK2_yZJCiNhpSL b2utRE1QHUh7otEGlwk3ngsyh8p1zZgpw05Hw5Zge9qGQy9Z2dkLvZFXIxuMgba11DJm9vprBblC cfzEczyhZK0AKoenzsXM7VhxLHnjhzM9cFR0.nzA5S9Rw5rjCx3zQXU8lYV7DQI6u8yzKZBAMlIQ vxLLRiirRwj3m.dLruKSv1nspYgiJBpMAoKU6oKcRs X-Sonic-MF: X-Sonic-ID: 4bec10c6-2461-4ffd-b35e-057f1186e790 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Fri, 10 Nov 2023 00:32:30 +0000 Original-Received: by hermes--production-sg3-8696d769c6-lsp29 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b8016c3cb1d17ccc0bf29e4c68a79c39; Fri, 10 Nov 2023 00:32:24 +0000 (UTC) In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Thu, 9 Nov 2023 14:28:46 +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.191.206; envelope-from=luangruo@yahoo.com; helo=sonic312-25.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:312449 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > Are _you_ the suit? I missed the point of most of your very > elegant text, but isn't policy-making exactly what you (and I) are > trying to do, i.e. discourage some things and encourage others? I'm not advocating partitioning Elisp into compartments, and to give countenance to some of them on the grounds of the stature of their designers. That's your proposal. My synthesis is roughly as follows: 1. cl-lib is a comparatively large file. 2. cl-lib is frequently loaded to provide trivial functions which could effortlessly be replaced by built-in constructs. 3. cl-lib also defines a number of functions imported from a different programming language, the beliefs underlying whose design don't align with those of Emacs. Therefore, we should discourage cl-lib from being introduced in the first place, because its proliferation will render programmers more eager to use it without considering its implications. > What's the gripe with compartments? We don't have all of Elisp in > a single library? I was talking about namespaces by the way, > if you didn't catch the reference (admittedly obscure) Because Elisp isn't naturally partitioned into "compartments." The basic unit into which our code is divided is the file, and all considerations must be framed on that basis. > Also, is really cl-set-difference to take the difference > of two sets worse than writing a "hallowed" multi-line > construct?? Maybe I'm not seeing what the construct is, so > what is your preferred Elisp hallowed way to take the > difference of two sets, say make a list that contains > all items that appear in LIST1 but not LIST2? Or to find > the index of a certain element of a sequence... dolist with a catch/throw, or dolist, member and push? > These comparisons, taken one by one, are the hard evidence of that > allows us to determine what is "alien" or not, not theological > consecrations of personal tastes of a given group, _any_ group. > For example, I don't think your 'nconc' form is more readable > than 'cl-list*'. It's slightly less readable IMO. We could alias > `list*` to nconc though, even better. But I can agree it's not > worth requiring cl-lib.el just for cl-list* alone. > > Much like you prefer setcar to rplacd. Which I also do, btw. But > I prefer (setf (car ...)) even more. But you'll frequently see > me using setcar and setcdr (or even rplacwahtevercannevertypeit) > if that's the style of the file I'm working on. Because I too > have my personal tastes, but contrary to others I can let go of > them without too much fuss. My point was that comparing rplaca to cl-lib is much the same as comparing apples to oranges, since rplaca is an _alias_ to setcar. > Stefan M's pcase in particular is great. Its docstring is tough, > I agree, and could use some examples (I always end up grepping > for examples). But that macro is a lifesaver. > > The way you talk about seq.el and pcase.el makes me think you > want to ban _all the things_, not just cl-lib. I'm confused about > what you want Elisp code in core to look like. Well, touch-screen.el is a good example of that.