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 20:52:32 +0800 Message-ID: <87cywhsrcf.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> <8734xetjkk.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="12836"; 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 13:53:37 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 1r1R0z-000397-5u for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Nov 2023 13:53:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1R0F-00082p-4z; Fri, 10 Nov 2023 07:52:51 -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 1r1R0C-00082Q-EB for emacs-devel@gnu.org; Fri, 10 Nov 2023 07:52:48 -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 1r1R08-0001vx-BY for emacs-devel@gnu.org; Fri, 10 Nov 2023 07:52:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1699620760; bh=hbUi5kEj7eBXtqy/Lf1f4TMhSvQq6gC+Sg+FflP0W9c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=IM85No1o/ojWUYpw2om0f9uzIViBPwVgPTEGjosk2djW37Z8ZaZfRpzfaHtnxHRyAwVO10xrgGkpnyVckyZ9Kg+U3iWN/EryuQG4zgtRIDv45uv/2TWmkbbF8LNB5ThkwOBgOXSIh2QMBQ9ByJIR1y5kOEj+qciwZMjgAcDdeekhQnqQpDpuGrT+SJ5Ahe4mxgXbjnLXwNQ9QcY2WQ/33jXRyYdub5NmTaEAw3hnQDmXU7XtJuME0/udyvEB6O/IIofZlF7q4XS0vk79w+4jSH3sg1kVDPzmNmhG66o9hVPHu1dl8a3OFIrnOvr+ON69+ZlIDtsS/KnsDo5fGcND4Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1699620760; bh=lr8bpFn6bG6947iIsqj41yKpi0Dt+x1yAVRm+zyvYnS=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=oeMbcZv7s/elBc6azf2I38azmae65Ih7CbLu21Dkg60agVVYg1S2hz5Zr/BRd1qj9pB2X0GYtDX9HzoAkgrS8pLQt9qzWPLsafy6/ferRQF736id40fE84dkrRaT3xa9Q+ol3tZcHKPuElIVMyInoDZQLZl/mxqM1S+lpoQmbLmawY8r4OMVNDOqCd4VRe2jn4Jw9RX143T7hVogPjdLcoNzhZGIWLVCKWPQ9zVd8lEUhlCwCoosqM1q+UWEt2WWlj7z6Y7Y5PumXx3ZAST8oHyfLxmSsa+1YgJahXwvVL36SDZmuBBQpDFUyAaSEHaBvgsCQKXeNngS8W4h1QeJ+w== X-YMail-OSG: WBuuITMVM1kJJJM7KcXcRwd_XEU1XgieApxrtDAzkSu69_CzVgCGVydZP42c7p5 VRo2rwaWYawAW1tBxQI9NeWustnpoWLxiLH0vqPaTCwaPs32RQ6HGAxpXz4ia5gHRCmU5dbRSW9f g9OIDtB3OfC5wdunLLwZe3wvMeWq1kI9TaUcbdIJwDaEd2TCOYa0rEcK0zMUB2zs9jg9Dkun_VFx MIW.AToMkeWQr6gpF8_lW3GBqPSu3AJjvmBfzF8sY7ZfXf5tUUpQ5YtBdMzOIs1ltvor5TPiG1bk IVI29FbcubUoIzt0MhiPFYjiI5ceQI1lmds5qBu2HFgb.zyb208v6oNt90yW.e1qhvtpuzHVpxMu rmRLqe30GqakmKd3qRCDDNiz87DFFV_X3kQhe_ckmpKlCnw8s9ivSiVZWZ7ffbleIm_tMbXxd1xR 9GzqP_sbseVxhHbzJdPuV4ny3UN6I1Rj701Oe9RPTj4F_uYUglBeMrLM517o5FVfzJMeXbMTutFH DD2zT9MST_GTk8Qrsj0uLOsK.DjYJI_21VTGgYzPJCfe.DeSyuQMqtA6EFarA1Qv8uJfqIaEp23p dFBziJDd7H0rNwdj9RH1_LsCTFmCUe_x_FO_oSaYzloB3quzc2XyWyHKnGKAZcR9mWh34r40M7ZD SH7zrfWXGYxXYNVi0Z7G0nWSAlCaxCTC.dbRTIyPqJY4H_xvIEUwhdFPUpKhIM_KfqAJCeh6HOVF o1m3GddunJMmP5jKWtFMpcJsyTY.ItmxdTHIpq6EmJrfs.6HnqJE6IlEk6_QhJQMMB1gK1R5GFOx czqm10khC9CG.NXxDvjUuGvVT0yGxnXbryZepJhvHG X-Sonic-MF: X-Sonic-ID: 9390ba30-95f0-48eb-a144-6b8e3ff7c4e1 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Fri, 10 Nov 2023 12:52:40 +0000 Original-Received: by hermes--production-sg3-8696d769c6-p7cfj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e06080310efa991ee24ee9853c1e58a6; Fri, 10 Nov 2023 12:52:37 +0000 (UTC) In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Fri, 10 Nov 2023 11:11:15 +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:312481 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > You're just contradicting yourself. First, you argue that it's easy > to replace and has these immediate benefits and then when someone agrees > with you, you say you don't want to. I didn't say I don't want to, I said that removing this one instance will not solve the underlying readiness to resort to _non-preloaded_ files, of which cl-lib is one, and an egregious offender. > Also btw, it might not be easy to replace at all cl-list* can be used > with higher order #'apply in contexts where nconc can't. Perhaps > you despise the programmer who wrote > > (apply #'cl-list* input-data) > > But perhaps they did it to avoid writing a multi-line raw loop choo choo > train again. > > So it's not true what you said originally that everytime you find a > cl-list* it can be cleanly replaced by nconc. Not if you understand > or even appreciate function composition. I don't appreciate "function combination," whatever that is. In a language such as C, the function of a single block is clear. Each block commences with a list of one declarator for each variable. Variables are supplied to and operated on by a list of arithmetic or data operators and procedures, subject to control constructs all programmers learn, and a value derived from one or more expressions holding these variables is returned to complete the block's procedure. Thus as data changes hands between operators, functions and variables, its movement can be discerned with only a handful of operators and control constructs in memory. This is how a computer operates, or what _you_ do when working out long division on a piece of paper, or when you set yourself to any other task entailing the observation of a series of steps while responding to changing circumstances in the process. Emacs Lisp is well capable of aligning to such requirements as well; today many would implement the old float-to-string with cl-loop and floating point numbers with structs, but in the past they were implemented with cons cells and while loops, without us being any the worse for wear. (defun float-to-string (fnum &optional sci) "Convert the floating point number to a decimal string. Optional second argument non-nil means use scientific notation." (let* ((value (fabs fnum)) (sign (< (car fnum) 0)) (power 0) (result 0) (str "")=20 (temp 0) (pow10 _f1)) (if (f=3D fnum _f0) "0" (if (f>=3D value _f1) ; find largest power of 10 <=3D value (progn ; value >=3D 1, power is positive (while (f<=3D (setq temp (f* pow10 highest-power-of-10)) value) (setq pow10 temp power (+ power decimal-digits))) (while (f<=3D (setq temp (f* pow10 _f10)) value) (setq pow10 temp power (1+ power)))) (progn ; value < 1, power is negative (while (f> (setq temp (f/ pow10 highest-power-of-10)) value) (setq pow10 temp power (- power decimal-digits))) (while (f> pow10 value) (setq pow10 (f/ pow10 _f10) power (1- power))))) ; get value in range 100000 to 999999 (setq value (f* (f/ value pow10) all-decimal-digs-minval) result (ftrunc value)) (let (int) (if (f> (f- value result) _f1/2) ; round up if remainder > 0.5 (setq int (1+ (fint result))) (setq int (fint result))) (setq str (int-to-string int)) (if (>=3D int 1000000) (setq power (1+ power)))) (if sci ; scientific notation (setq str (concat (substring str 0 1) "." (substring str 1) "E" (int-to-string power))) ; regular decimal string (cond ((>=3D power (1- decimal-digits)) ; large power, append zeroes (let ((zeroes (- power decimal-digits))) (while (natnump zeroes) (setq str (concat str "0") zeroes (1- zeroes))))) ; negative power, prepend decimal ((< power 0) ; point and zeroes (let ((zeroes (- (- power) 2))) (while (natnump zeroes) (setq str (concat "0" str) zeroes (1- zeroes))) (setq str (concat "0." str)))) (t ; in range, insert decimal point (setq str (concat (substring str 0 (1+ power)) "." (substring str (1+ power))))))) (if sign ; if negative, prepend minus sign (concat "-" str) str)))) If it is to these that you apply the moniker "multi-line raw loop choo choo trains," then they are precisely what should be written more, not less. The "Lisp way" (more felicitously the cl-lib way) is to provide functions to truckloads of other functions which interface them with one another. Each such function is a unique control construct. To glean what a function does, one must not only commit each of these control constructs to memory, but as is all too often the case when the functions provided to the control constructs are beyond its control, also examine each of its callers, with labyrinths that put C++ to shame into the bargain, like pcase-lambda and macros which rewrite the control flow of a form beyond recognition. > Be consistent: find the places using simple forms of cl-list* that > presumably (as you said) are the only motivations for the whole > cl-lib.el 27kb loading. I didn't check but this was your opening > argument after all. So do that and you'll have effectively and > consensually helped Emacs's code base. You'll be closer to your > dream goal, using Emacs without loading cl-lib.el. Be consistent > with your words, else you're just hand-waving and advocating > for irrationality. "develop a general aversion"??? I like to think > of programmers as scientists, not acolytes to some sect. If such invective and an unwillingness to reason from the specific to the general is the best response you have, I won't condescend to answer.