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 10:34:22 +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="17466"; 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 11:35:23 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 1r12Nf-0004If-7q for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Nov 2023 11:35:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r12Mo-000150-U8; Thu, 09 Nov 2023 05:34: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 1r12Mm-00012X-Uo for emacs-devel@gnu.org; Thu, 09 Nov 2023 05:34:28 -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 1r12Mk-0000Tn-QR for emacs-devel@gnu.org; Thu, 09 Nov 2023 05:34:28 -0500 Original-Received: (qmail 60388 invoked by uid 3782); 9 Nov 2023 11:34:23 +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 11:34:23 +0100 Original-Received: (qmail 3060 invoked by uid 1000); 9 Nov 2023 10:34:22 -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:312393 Archived-At: 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: 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). Having done this, we recode code currently using those deprecated f/m/v. (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).