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: Mon, 23 Oct 2023 14:18:51 +0200 Message-ID: <87lebtmt04.fsf@dataswamp.org> References: <835y38qvlg.fsf@gnu.org> <87bkcx6eci.fsf@dataswamp.org> <83ttqnm4ti.fsf@gnu.org> <87r0lqoo5x.fsf@dataswamp.org> <83msweu76j.fsf@gnu.org> <87o7gungi1.fsf@dataswamp.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="26093"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:zgJzNi/7W0ufQKZq0WjtQqByEao= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 23 14:45:45 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 1quuJV-0006al-HV for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Oct 2023 14:45:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1quuId-00067i-Rc; Mon, 23 Oct 2023 08:44:55 -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 1quttj-000357-7m for emacs-devel@gnu.org; Mon, 23 Oct 2023 08:19:07 -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 1qutth-0005bd-6c for emacs-devel@gnu.org; Mon, 23 Oct 2023 08:19:06 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1quttf-0000wV-TP for emacs-devel@gnu.org; Mon, 23 Oct 2023 14:19:03 +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: Mon, 23 Oct 2023 08:44:28 -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:311707 Archived-At: Alan Mackenzie wrote: >> From my point of view in some way it does sound like that >> some are against it [the use of cl-lib] for ideological >> reasons rather than technical. E.g. those that makes code >> unreadable or lets rewrite something to drop the dependency >> to not load it. > > You seem to be saying that avoiding making code unreadable > (i.e. difficult to maintain) is an "ideological" thing. >From Eli we heard cl-lib adds bloat and fills up the global namespace. From RMS and you we hear it makes code more difficult to maintain. At the same time Eli says it is just another Elisp package and library which should be treated as any other, i.e. it should only be used and brought in when needed. This, of course, I think everyone will agree on. But the other arguments are more difficult to see from here. Rather than bloat and filling up the namespace unnecessarily, I think it makes Elisp more powerful. So to me, cl-lib is a good example och packages we do want, and the more the merrier. When there is no clear way to do something using non-cl-lib Elisp, I see no harm in using cl-lib (on the contrary) and I still don't understand why it appears to be considered OK in some places and some stages of Emacs execution and not others. Wherever it is useful and provides expressive and computational power otherwise unavailable, it should be OK to use. With the possible exception of 'emacs -Q', since there the minimalist policy makes sense and one can make that argument. One can also think that cl-lib's presence can bring guys from the Common Lisp world here, which is of course a positive thing. And it doesn't mean now all Emacs will be Common Lisp. > That's a big "when" you use. If the use of cl-lib actually > did make things "easier to understand", I would agree with > you. But it doesn't. E.g. (cl-incf some-var) isn't better and more clean than (setq some-var (1+ some-var)) ? I think it is! Other examples are, as has been mentioned, `cl-decf' and `cl-pushnew'. I can see that `cl-loop' has some higher threshold to understand and to get used to but (1) it adds so much expressive power increase in complexity is unavoidable and expected; and, (2) it still should be no match for programmers maintaining Emacs? > As an example, take the last macro in cl-macs.el, > `cl-deftype'. Its doc string is just [...] Well, we should improve the docstrings whenever they are insufficient, this is the same as any other library. >> 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. > > I have outlined a reason above. Fifty years ago, you could > have been saying the same about the goto statement. 50 years ago, some programming languages were so limited the goto was needed. Today, some are so powerful, one can add cl-lib to make them even better. And indeed, we now have `cl-return', even ;) -- underground experts united https://dataswamp.org/~incal