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 16:09:42 +0200 Message-ID: <838r74wfdl.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> <83wmuowwp3.fsf@gnu.org> <83cywgwg3z.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17164"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael_heerdegen@web.de, emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 11 15:10:20 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 1r1ogm-0004EX-DJ for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 15:10:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1ogK-0006Za-54; Sat, 11 Nov 2023 09:09:52 -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 1r1ogI-0006ZK-LX for emacs-devel@gnu.org; Sat, 11 Nov 2023 09:09:50 -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 1r1ogI-0007jM-Cr; Sat, 11 Nov 2023 09:09:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=nEPaB9RMdz2yGUqQTLSWwTBbObiQqWCwmKx+qZuj2aU=; b=j6SGDTUj+Myhuu2kKwYQ A9YM3BlEFOR/GJzfjJRlVlfZLhxl7uIYNxojF0ML9PO+3Pr4Zf4oPCljuZjPEIdAyc4/Vn1KQhKRz KeeElMRIOKA/Tx/dBLMo6LMNGtV2AghI0WlFBKzyi678iFL6CxmopFnuQgPA4NQHM7hPmi4dBNECf m5inTlIGpGVucM1O+bSTWk8qNTzCeO1sQxoWBTF4gwVVJ48moZhszWg77JXQq/WhZRHNHhcxisHnQ YfWtxJ9aCZS87JtW+hIdGXXv7sqWd9zWUqzXDrnaHAnLngmK1TTOmzXLEr7lKCrakcX+uUKh5w0ry 4V/HzAYjhRSchA==; In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Sat, 11 Nov 2023 14:01:24 +0000) 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:312573 Archived-At: > From: João Távora > Date: Sat, 11 Nov 2023 14:01:24 +0000 > Cc: michael_heerdegen@web.de, emacs-devel@gnu.org > > On Sat, Nov 11, 2023 at 1:54 PM Eli Zaretskii wrote: > > > > I generally agree with the goal of bringing in cl-lib.el ideas into > > > core, but it must be said here that seq.el, despite being a sequence > > > processing library, should NOT be viewed as a drop-in replacement > > > for cl-lib.el counterparts > > > > That (and the rest of your message) completely misses my point, and > > doesn't even belong to this discussion, to tell the truth. > > I think addressed your suggestion to have "similar or identical > implementation [to cl-lib.el] in the likes of [..] seq.el" quite > directly. In my suggestion seq.el was just one of the examples not the only, nor the main, package for such additions. So making it the only one, and then objecting only to that, is a kind of a strawman, and completely misses my point. I included seq.el because I see nothing wrong with adding cl-defmethods to seq.el with more efficient implementations for specific types of sequences. Whether it does or doesn't make sense depends on the specifics, which are not on the table at this time. I certainly don't agree with rejecting the idea of adding specific implementations to seq.el, let alone its wholesale rejection, and I likewise agree that in some cases adding a specific implementation to subr.el or somesuch could be a better idea.