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 21:14:25 +0800 Message-ID: <878r75sqby.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> <87il6bt4z0.fsf@yahoo.com> <87y1f6s3eb.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="1525"; 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 14:15: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 1r1RME-0000GC-OH for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Nov 2023 14:15:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1RLN-0007R1-UP; Fri, 10 Nov 2023 08:14:42 -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 1r1RLL-0007Qm-Ad for emacs-devel@gnu.org; Fri, 10 Nov 2023 08:14:39 -0500 Original-Received: from sonic301-31.consmr.mail.ne1.yahoo.com ([66.163.184.200]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r1RLI-0008PQ-PU for emacs-devel@gnu.org; Fri, 10 Nov 2023 08:14:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1699622073; bh=gvfxuMX2cEkA2Tbf7Zpy+2w+QoLRQ0AcgkgRPjdn+r8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=HoT7o1w4zTmqL9HdxSpPFdRUzMGDcr+zMGT161SgQF3B6Kf1G0nu1VxL7xevwX/FaMGpbr09lSpgiSsOVRrdfOEs2/7KOe5bs96NgtZZQ6+ogA7a3s2HqhzLRVa4ht+J+9oNyZQzOOvDNb8li2KYdk/8nS+6Jw7bFkf8a7oiNF18JYG/BdwimNVqhyceLptjgy2aeQcaC04VzHX9VkGBIa1mEK0y88hG9gZN3lhA/oNyIgxiItFGbxbKYbmBtS8UhdrrtT4EsAbILGzXlI2Kr0R5eSw42ieql65M2xmPirctJib4iM9nm+92iLkV7wCc/OKRTvYPkpMs6AlZN+8DAw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1699622073; bh=UpBPGBrO9ptf+wCTIoni73FzCCC2nsk1cxcaQoPpcYP=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=r3/pGiw0AHFkR+bnP2I/ajALPrjEHEcymeA+g6wBXPe0U7EMeqXXw/rFGedAsktBPGM2SUb2e4iAZJmIs4kS5KbO3z4T5wgadwXoBd9/S9ropMR+Cz7z1XQt1aKKcX+lz+UQ97EPwsMirhrbhH88Qkl83iZx8zViXHIRZ/R3vj7r45GWMSUlFnnrZ0ciNdUT16+WL6zC5ox1kfWtzB62+Z0KyG84nzxx9Q/27pLNhaptqLqCqAxun3njECdY2CoDSCPwOOxMeJb/I8xq5YzaomJXusYpLjwB+b6HHaYqhCkCMPyYFuJzYNX5CRRIbisrFhaOqkEMRAMdOyyH3qRuGQ== X-YMail-OSG: HthGzgoVM1neoeGzVf277SRd_r6xFM8M0uoo97MxLwlj9nxVcd02goD1rZwsGUt f4rwi88qpn8pBjN3EfgFMO1pKr16bI.TnWtSyzre1Td5RJGFugCYBR.jczt6LmHo.4Kf3yU5316N sjgMFDmMGKBFeHs2roGfj6hFw6q5UjcsjtuK2Nc_WATY6YtlG5F8ocAAaUdR0r7jbJ5YvwWPCWi_ GRQVR2FpP0xZZ_X.VKVFwMI1T.NhGMD9a0zWmOc94NzM0OalPgIMt.8ibUxlHvpXohZ7b6zr7Qjy 6kVgr.puneg7p7hWTmeCEuc._ZyZweZ5DzMjBCErVlw37Or3LifMmbaNqTpXqxhSQsRJqPqWNQmM J9.32D1ooYLsPJb_RcppPJN.FuDU17QHxPCxNo5WurEjvzX2v7RzoubAFBOxM5ioPGGmDVKHSl24 ijjCEiXfzYelaTX5NkaBjmUxDKsxCW_TMY9yb8JbYnXpJzXy77SpbTDCVXPnAwb6ubmBHXzK.rrX PevetcUiZSjlqfSruc0iCiqTEr400b.CTyD0TzAk_HZ6qXyWXFjQUxRpoR642d7lUZ1_4Mtw8MFB 4Mha3m54abWqrTSrAZvTyoshwJsMIGeFCR1tkYN3Bqm8TehgRqUBC8CiCaQDm78WBP5fjZFZMdRE YhMMZ13jrgZidjfZq47vDsOo4uDMogpq_6Gwu_3m66RHTO_B7AqIR2XB2QbdlJXMhNvouMP6_oIe zk6RHdZ6NGtA._rKXg3wF9oNR70roMknlLR.D4pGQcGaJ4j.NmE9MKw4UQPfAGuJlUyNUj3v40rq LysqwlXFKdRva_73bkHvJFqtyUrx9BKT3c4VhJqsUK X-Sonic-MF: X-Sonic-ID: a19314b6-75f3-4201-a861-ad23fbef4927 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Fri, 10 Nov 2023 13:14:33 +0000 Original-Received: by hermes--production-sg3-8696d769c6-r64c6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID efad1ab7d5bc286a91ffac8b49d49271; Fri, 10 Nov 2023 13:14:30 +0000 (UTC) In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Fri, 10 Nov 2023 10:54:08 +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.200; envelope-from=luangruo@yahoo.com; helo=sonic301-31.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:312484 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > But that leitmotif is everywhere (and us much less strong in open-source, > btw). Surely if you've ever worked at a large enough company you'll see > bizarre code from people not working there anymore. Where I work, our practices and policies prevent these difficulties from ever materializing. Think a standardized coding style, mandatory quotas for documentation length, expositions written and, hmm, anthologized independently of the code itself, and review by individuals who have, needless to say, never seen the code before in their lives, and will not so much as bat an eyelid before striking down code they cannot easily understand. The first and third are what's being proposed here for Emacs, unless I'm greatly mistaken. > And that goes for everything. You think everyone will forever be > grateful to read your 300-line inline-all-the-things functions in > touch-screen.el when you're not around to explain what they do? They > won't. It's well-documented and in line with other Emacs Lisp code, so I think they will. Indeed one individual is already implementing the recognition of panning and zoom gestures with it as a basis, without any counsel from me besides referring him to the file itself. > It makes no sense to single out any given library for this evil, > especially not cl-lib.el which is a well-understood stable piece of > kit. In Emacs core and just as strongly outside it. See what I explained earlier. > Many examples of Emacs Lisp functions take them. Like? Which list manipulation functions do? Contrast cl-member to member. > Even Richard seems to have come around to their usefulness. CL > functions take them in consistent ways, but you can use them without > keyword arguments if you're stubborn enough. Anyway, it's not a > "belief", it's just a good way to provide versatility for functions. A "belief" in this sense is a model or general scheme that is adhered to when designing a function, of course, so let's not descend into quibbling. > Why do you exempt yourself from this irresponsibility? Can't you see > this is all subjective and it seems a bit arrogant to say "my code is > so responsible"?? Thus far there have been no complaints that code _without_ cl-lib, pcase, seq or elt is unreadable. Most of our code (this time measured by lines) falls squarely within that category. > All code is bad. With that outlook, there's not much of a purpose in writing any code for Emacs, is there? >> > Hmmm, a bit vague, no? Humor me: if it's really so easy and so >> > readable please write out your preferred equivalent of, say >> > >> > (cl-set-difference l1 l2) ; hopefully obvious, like l1 - l2 in pyth= on >> >> (let ((list nil)) >> (dolist (x l1) >> (unless (member x l2) >> (push x list))) >> (dolist (x l2) >> (unless (member x l1) >> (push x list))) >> list) > >> >> (catch 'tag >> (let ((index 0)) >> (dolist (tem someseq) >> (when (eq (car tem) probe) >> (throw 'tag index)) >> (setq index (1+ index))))) > > Nuff said :-) . So if multiple set difference operations or multiple > index-finding operations are needed you write these choo-choo trains > again and again. That sure explains the 300 lines. Sure, but catch, let, dolist, when, throw, setq and member are elementary operations under Emacs Lisp everyone learns. They are also few in number. > I guess not for human versions of --finline-functions who think, or > rather "believe" that such common practices for code reuse as > subroutine encapsulation is "balkanization". It's probably "patently > absurd" for them yes. But the Emacs Lisp compiler doesn't inline functions, does it? At any rate you have conflated one of my statements with the other, so read again. Thanks.