From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Sat, 11 Nov 2023 09:55:36 +0200 Message-ID: <83wmuowwp3.fsf@gnu.org> 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> <87cywgx1z0.fsf@web.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27164"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 11 08:56:37 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 1r1ir4-0006pt-UW for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 08:56:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1iqH-000164-B4; Sat, 11 Nov 2023 02:55:45 -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 1r1iqF-00015t-9E for emacs-devel@gnu.org; Sat, 11 Nov 2023 02:55:43 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1iqF-0007Xh-13; Sat, 11 Nov 2023 02:55:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=2sG8FRcaVvDKdcum1UOTsKxRMv9qMqvY7voxDtle6T4=; b=hH/wsK1hsvwH 3knTtghNbxojaVDWJ7rFJRGiYJ6tKapf56v3Ec05i9qzNtPlCfhgneHLqxXNFW1hdjucVE/IkAatn KoyPpBpRLc3ihPGCtR2lDhcbVLg3Kmfj7OF0QRTcruDb3SJqvt0WmfGHsEkCkEpwhDIvDrsHT4gJ5 FZs9SEgHc2VJex9+ChjgL6cgjTii3N4asEp1XU5VYJWv3GJJGEtsR7W7t+JkUsBjlRFTW663vUEGZ /SogP8Zq8ItaKJtNqBiQbhVAKhnSbJyCrHxEXif/k6O77jVnul0YuHJiDkWagSZPpTuZKr3n5vOM7 uvw91MG5D7ZtrIiiBfcRhg==; In-Reply-To: <87cywgx1z0.fsf@web.de> (message from Michael Heerdegen on Sat, 11 Nov 2023 07:01:39 +0100) 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:312532 Archived-At: > From: Michael Heerdegen > Date: Sat, 11 Nov 2023 07:01:39 +0100 > > 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 These are exactly our goals. We've been doing this for years: that's how stuff like 'when', 'unless', 'push', 'pop', and others got into the core. IOW, the way to make some cl-lib functionality freely available in core is to have a similar or identical implementation in the likes of subr.el or seq.el, using our naming convention instead of cl-FOO. We've been doing that for many years, and we will continue doing it. People just have to understand that this is the way. The problem (at least my problem) is that some of the people in this discussion don't agree with this cautious and slow approach. They want the unconstrained liberty of using all or most of cl-lib and its extra libraries everywhere, and they consider any request to avoid using these facilities an unacceptable pressure. They basically want cl-lib, cl-extra, etc. preloaded and always available for use, regardless of the aspects you mention above and without any restrictions. So your argument is not with Po Lu, your argument is with others. > 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 use keyword arguments when there are many of them, or when a few of them are obscure and rarely used. From where I stand, the dispute is not about banishing then -- that will not happen -- the dispute is about how _much_ to use them.