From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Thu, 9 Nov 2023 14:49:24 +0000 Message-ID: References: <871qd8sfdx.fsf@posteo.net> <838r7g8pys.fsf@gnu.org> <87bkcbrgnr.fsf@posteo.net> <25924.21015.19614.951576@orion.rgrjr.com> <87bkc4jpja.fsf@dataswamp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15734"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?iso-8859-1?Q?Bj=F6rn?= Bidar , emacs-devel@gnu.org To: Gerd =?iso-8859-1?Q?M=F6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 09 15:50:30 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 1r16MX-0003wT-IY for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Nov 2023 15:50:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r16Lb-0002Is-HC; Thu, 09 Nov 2023 09:49:31 -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 1r16La-0002Ij-AL for emacs-devel@gnu.org; Thu, 09 Nov 2023 09:49:30 -0500 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r16LY-0001Wa-6a for emacs-devel@gnu.org; Thu, 09 Nov 2023 09:49:30 -0500 Original-Received: (qmail 54720 invoked by uid 3782); 9 Nov 2023 15:49:25 +0100 Original-Received: from acm.muc.de (p4fe15b72.dip0.t-ipconnect.de [79.225.91.114]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 09 Nov 2023 15:49:25 +0100 Original-Received: (qmail 4702 invoked by uid 1000); 9 Nov 2023 14:49:24 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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:312413 Archived-At: Hello, Gerd. On Thu, Nov 09, 2023 at 13:19:28 +0100, Gerd Möllmann wrote: > Alan Mackenzie writes: > > On Thu, Nov 09, 2023 at 08:24:14 +0100, Gerd Möllmann wrote: > >> Alan Mackenzie writes: > >>>Just take one look at this "reality" you're so supportive of: the > >>>widespread use of cl-lib, not just in people's own projects, but > >>>throughout the core of Emacs, has multiplied the size of Lisp language > >>>part of Emacs by a factor of around 3. This is a gross increase in > >>>complexity for maintainers that is not justified by the slight increase > >>>in facility that cl-lib (along with things like seq.el and oclosures) > >>>gives. > >>>Throughout this long discussion, this indiscriminate use of cl-lib has > >>>been supported only by occasional contributers. Those who actually > >>>maintain other people's code, apart from (I think) Eli, Richard and > >>>myself, have been conspicuously silent. None of us three have favoured > >>>such use of cl-lib. > >>>Occasional contributors may be fascinated by cl-lib, and learn enough > >>>of it to use random bits of it in their code. The trouble is, each > >>>such contributor uses a different piece of cl-lib, with the result that > >>>those who end up maintaining it need to know a far greater part of it > >>>just to cope. > >>>This factor of 3 is, I believe, a significant barrier to new > >>>programmers coming into Emacs; Elisp is just that much more difficult > >>>than it was in the past. And it isn't just for newcomers that it is > >>>more difficult. I spend a significant amount of debugging time having > >>>to look up doc strings and manual pages for obscure cl-lib (etc.) > >>>functions. > >> > That is the current reality. > >> Maybe you could elaborate on what the plan then could look like? > >> Or is it not about a plan, but something else? > > You stripped all the context. I've put it back again. > > As a concrete plan, I would propose the following for discussion: > Thanks for that. I find it much easier to digest than this clean/unclean > thing. > And wow, that will not be popular :-). It will be a mixed popular/unpopular, with probably few people in the middle. Back when you were the Maintainer, I think there was a ban on the use of cl.el and friends, except for at compilation time. I don't think that caused any problems. > > We should deprecate those functions/macros/variables in cl-lib that have > > no doc string, or a substandard one. This includes "internal" functions, > > too. Also to be deprecated are obscure functions/m/v (such as > > cl-labels). > Am I right in assuming that this is not about the documentation itself, > but just some selection criterium for reducing the size of cl-lib? The most troublesome cl-lib functions are those without adequate documentation. They're the ones that waste unbounded amounts of time when trying to debug something which uses them. That's why I'd like to do away with them. There are few people willing to fix the doc strings in cl-lib, though João has volunteered to make a start. > > Having done this, we recode code currently using those deprecated > > f/m/v. > What would recode mean? Using seq/map? I hadn't really thought of seq.el or map.el. What do they do? But it's clear that working code can be written without these or cl-lib. > > (Here a "substandard" doc string is contrasted with an adequate one, > > which does all of the following: > > (i) It says what the function/macro _does_, or what the variable _is_. > > (ii) It describes the form and meaning of each parameter, and its > > relationship to (i). > > (iii) If the return value is significant, it describes this. > > (iv) It describes all effects on the global state, such as where it > > writes results to, and suchlike.) > > This would reduce the size of cl-lib to something more manageable than > > what we have at the moment. -- Alan Mackenzie (Nuremberg, Germany).