From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Sat, 11 Nov 2023 07:01:39 +0100 Message-ID: <87cywgx1z0.fsf@web.de> 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> <87cywhsrcf.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26120"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:5T07C23PczjNpoEw3FnnPzSDZQQ= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 11 07:02: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 1r1h4l-0006ep-Fi for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 07:02:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1h3v-0003vz-07; Sat, 11 Nov 2023 01:01:43 -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 1r1h3s-0003vq-Ib for emacs-devel@gnu.org; Sat, 11 Nov 2023 01:01:40 -0500 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 1r1h3q-00022q-Qj for emacs-devel@gnu.org; Sat, 11 Nov 2023 01:01:40 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1r1h3l-0005OY-Er for emacs-devel@gnu.org; Sat, 11 Nov 2023 07:01:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ 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: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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:312523 Archived-At: Po Lu writes: > 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. > [...] > 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. Side note: I'm not a "fan" of cl-lib, and I hate cl-loop. I hate it when I need to understand code that uses it. But this discussion has some aspects that I don't like - forcing other programmers to share the own likes and ways of programming, "without discussing each decision" although these decision have a very broad reach, are backward incompatible and throw away the long-year work of very committed and not unintelligent people. Be aware that some things in cl-lib are very well written and you'll need a very long time to to develop a replacement of even approximate quality. This discussion has too much from "Personally I don't like this, let's just throw it all away and start from scratch" that I only know from maybe a bit naive people in emacs-help. I understand most of your points of criticism. A lot of parts of cl-lib are not very useful for core Emacs, are harmful when used, should be avoided as much as possible. OTOH, there also are the useful things, `cl-labels' (it had been mentioned as a main example) is definitely among them for me. Simple, well-defined and used to implement other things... I can't believe that it is an expectation that somebody's personal preferences and likes should be the only guide of how to proceed. cl-lib started as emulation package for Common Lisp. It was a huge work to get it where it is now. We should definitely _not_ simply throw away this achievement. I see that some parts of cl-lib are not well documented, and there are problems when debugging it's stuff. But honestly, other parts of Emacs have the same problems. And the Edebug support of cl stuff has also improved in the last time - this is possible (this question only applies to macros anyway). FWIW, just as a random opinion, I found the original sparse documentation of `pcase' very fine (and yes, I understood it), so, please note, we are different people having a different background. Please, let's discuss this with a bit tolerance and a bit less anger and sarcasm. It is an important decision. My goal would be like this: - keep cl-lib available to it's current extent for end users - try to get unnecessary cl-lib uses out of the code base - make useful cl ideas available in the core language And: one main problem we have is that cl-lib is more or less a huge monolithic block (as a `require'able library). Why not split it up? I don't see why it is necessary that when I want to use a small useful cl thing that cl-loop must be made available. Such things could go to its own library, name it cl-obscure when you want. But I don't see a necessity to, for example, kick keyword support out of reach for the Emacs code base because, there are still, few, use cases where it fits. We don't want to end in a situation where we have 15 places that all reinvent the same wheel in subtly different ways. This would not be an improvement. There is no need to reinvent at all. This stuff is well tested and integrated. As long as the fundamental guideline is clear that using such features is limited to spare situations where it really makes things simpler, I don't see a problem, apart maybe from the fact that cl-lib is big. I would like us to try to factor it when the size is a problem (is it a practical, objective, or more or less mainly only a psychological problem btw? - that has actually been one of my main questions when following this thread). Michael.