From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: Lisp files that load cl-lib in problematical ways Date: Fri, 20 Oct 2023 05:02:14 +0200 Message-ID: <87o7gungi1.fsf@dataswamp.org> References: <87il8betof.fsf@dataswamp.org> <83fs3dgxv8.fsf@gnu.org> <835y38qvlg.fsf@gnu.org> <87bkcx6eci.fsf@dataswamp.org> <83ttqnm4ti.fsf@gnu.org> <87r0lqoo5x.fsf@dataswamp.org> <83msweu76j.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15509"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:oOc5htQspcwut6Qb+6jH6ZH+kLY= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 20 07:44:03 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 1qtiIk-0003pi-FS for ged-emacs-devel@m.gmane-mx.org; Fri, 20 Oct 2023 07:44:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qtiHz-0002ga-Tq; Fri, 20 Oct 2023 01:43:16 -0400 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 1qtfmV-0002mY-P7 for emacs-devel@gnu.org; Thu, 19 Oct 2023 23:02:35 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qtfmT-0000QC-S2 for emacs-devel@gnu.org; Thu, 19 Oct 2023 23:02:35 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qtfmR-0003ZD-VK for emacs-devel@gnu.org; Fri, 20 Oct 2023 05:02:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 20 Oct 2023 01:43:14 -0400 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:311610 Archived-At: Eli Zaretskii wrote: >> The "levels" introduced in this discussion are, it would >> seem >> >> - files that are used by vanilla Emacs that use cl-lib >> >> - such files that use it at compile time >> >> - such files that use it a run time >> >> - such files that are loaded when Emacs is executed with >> no arguments >> >> but - what is the difference? I think it is pretty clear >> that cl-lib is used quite broadly, probably because people >> find it useful. >> >> So what does it matter if it is "purged" from one or >> several of these levels? What gain is there if that >> is achieved? > > It matters to us because we decided long ago to avoid > loading cl-lib at runtime in vanilla Emacs. But as we have seen in practice it _is_ loaded, be it by the debugger, by native compilation, or any other package or piece of Elisp that uses it, or uses something else that is using it. It is all interconnected, and because it is used so much already, using Emacs in practice implies having cl-lib loaded at run time. > There are several good reasons: bloat, unnecessary namespace > pollution, etc. People use it because it is useful: there is `cl-loop', `cl-incf', `cl-decf', `cl-pushnew' and many others examples of that. Those are not complicated to use, they are all prefixed with cl- (as we see) and have good docstrings. > But all this is not really relevant for the code that you > (or any one of us) write for their own personal use, it is > only relevant to code contributed to Emacs. But we don't know what people who are starting to write Elisp today for their personal use go on to contribute to Emacs packages that make it to the ELPAs, or core Emacs for that matter. That whole distinction does not make any sense to me. If it is harmful, which it isn't, no one should use it and it doesn't matter in what context, be it personal use, ELPA packages, core Emacs, compile time, run time - what does it matter? On the other hand if it _is_ useful - and the number of people using it and the number of files where it is used, and the number of occurrences indicate that it is - there is no reason to disencourage people from using it, anywhere. You, and everyone else writing Elisp for that matter, are of coures equally permitted not to use it, if they consider it harmful, it just shouldn't be labeled detrimental as a policy with really no good arguments supporting that claim that we have seen thus far at least. -- underground experts united https://dataswamp.org/~incal