From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Mon, 13 Nov 2023 11:21:04 +0000 Message-ID: References: <87il6bt4z0.fsf@yahoo.com> <8734xetjkk.fsf@yahoo.com> <87cywhsrcf.fsf@yahoo.com> <87cywgx1z0.fsf@web.de> <83wmuowwp3.fsf@gnu.org> <8334xcwank.fsf@gnu.org> <320999cc-6c83-2315-0044-cc0403400af3@gutov.dev> <87ttpqjbka.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24806"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , =?UTF-8?Q?Gerd_M=C3=B6llmann?= , Eli Zaretskii , emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 13 12:22:13 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 1r2V1A-0006IN-NQ for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Nov 2023 12:22:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r2V0N-0000cv-Rf; Mon, 13 Nov 2023 06:21:23 -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 1r2V0L-0000cT-F4 for emacs-devel@gnu.org; Mon, 13 Nov 2023 06:21:21 -0500 Original-Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r2V0I-0003VM-TX; Mon, 13 Nov 2023 06:21:21 -0500 Original-Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-507c1936fd5so5927608e87.1; Mon, 13 Nov 2023 03:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699874477; x=1700479277; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MxASydGwkXqK704o8uS+T/gGkow7gL5xnSyeISk0tA8=; b=a5oMn8uzMwAC3ItjLB4U0sL3Ybd2TuQMJpgr4WWBeuA/FxLhxqctM0cYuqgStOVceP zWE07TybvW9jjZixEKeQYYZwl9d3UoWg+irbSEKZcMXI5SFRWCCuileF8W1Ni76K/Vw0 zleJk7Pva6Uq1gJBMSDELz4LAXctZLI/q1wY/4KbxnuIA/MbAw3JuYHzMDzIl2k6FEkK MPTzxCySvIqGY1AINgGMm3xoOpg+ALq8s1wbsSV4xa6vrR0X4NB/5HK4Rze3eKK+CF1Z CFaRCgNej5e4TuXGTQ7ZUXqwKnxebZLRPVAUM5ARTCztLvmezEvxqpKdXY27Ic6e008R dQnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699874477; x=1700479277; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MxASydGwkXqK704o8uS+T/gGkow7gL5xnSyeISk0tA8=; b=eL04WEaKiFMJ+SPTiCqSP+z4+InRlBge3WKefRV6K80CKhC8I2GguieB7ZpQtVHFBP hqAWGFU5U4IfAuumM+ncRdlUGeoVUzpPEglkjVq3H4oshXX1+KxQJQB0wH8DduU08yYD jG8aigr4Qpx+1vt9dzeaoI+8+f7y0ur+0ZVjHGOezuNuj4Lg8LkPhxHV4cvgaPw62Irx I3Zo3L6/yZ2jlkkwo0yCPM83+m0H8N2avY3PyjQdXegHufdl6Mq2eOfXBhtUZq8pGu5b ROymrC350UZjfrb+b6Pt09lz1+UfihYwnkBvObpOCL8fT4HilUjm6nuVoHpahOg1HN9l 3qPA== X-Gm-Message-State: AOJu0YwC04r8XOXkWpH+YwSlAYVRml1Dgu48vnfVxGsClhu8Rkz41Yke GMb5vDxyuQVWImuBeJ6uw26ClfMco/i3+t0Ru3k= X-Google-Smtp-Source: AGHT+IF7elr4xTheiN8D/VHUMCY45XO5Gh8B7AT/tmWgAKDf5MwgaiZVGeNURxuweDHUdes43LjbpQ3+ZBdKbWqPb4A= X-Received: by 2002:a05:6512:b20:b0:509:51df:c381 with SMTP id w32-20020a0565120b2000b0050951dfc381mr2928479lfu.12.1699874476458; Mon, 13 Nov 2023 03:21:16 -0800 (PST) In-Reply-To: <87ttpqjbka.fsf@web.de> Received-SPF: pass client-ip=2a00:1450:4864:20::134; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x134.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:312696 Archived-At: On Mon, Nov 13, 2023 at 8:34=E2=80=AFAM Michael Heerdegen wrote: > > Jo=C3=A3o T=C3=A1vora writes: > > > Maybe seq.el can be made faster too? Who knows, but it seems > > difficult without breaking at least some of its defgeneric-based > > contract. > > Of course can it, and it is not difficult in most cases. Go right ahead, presuming you understand the pros and cons. > For example, `cl-some' has two code paths, while `seq-some' has only one > that corresponds to the more general and slower one in `cl-some'. > Nothing forbids us to add the same optimization to the `seq-some' > algorithm. Sure you could have seq.el require 'cl-lib.el' ;-) Now really, sure? What about those generic functions that you presumably have to shortcut? Won't it break an existing contract to users that all of the sudden you're not calling them anymore for certain types of sequence? And how are you going to do this without introducing non-destructive versions of the seq.el utils? Isn't non-mutability in the contract? And wasn't it a goal here to end up with a smaller dictionary of such utils? Won't it bloat up comparibly to cl-lib while still being less versatile? These questions might have answers, of course, but they're not answers as trivial as you make them sound. > These kinds of benchmarks are more or less irrelevant. I beg to differ, I think a recommended sequence processing function that needlessly conses and takes orders of magnitude more time to do its job is really quite relevant. Elisp is still a "LISt Processing" language by and large. But also, I have to ask: what _would_ be a relevant benchmark to you? Just for cl-set-{n}difference, I'm seeing significant usage in core right now, direct _and_ indirect. I'm not sure all the authors, let alone users, of these packages would like to learn that these parts of their code have suddenly become a full order of magnitude slower, let alone users using such things, by virtue of some cl-lib.el -> seq.el operation as is being suggested here. At the very least, if this idea is to go ahead, answering all those questions about seq.el's performance and measuring everything twice should be a prerequisite. > seq.el is new > while cl-lib has been tuned and optimized for decades. No, the point is that it hasn't. Some of the destructive versions weren't even destructive at all! if you take a look at my code you'll notice I optimized cl-lib considerably in very few cases. There's a lot more that can be optimized there. Also it seems that the optional keyword arguments in these functions are not a cause for performance concerns at all, at least in these cases. So just for learning that, these benchmarks are useful. > Nobody has so > far ever decidedly tried to optimize seq.el with respect to efficiency. The seq.el file has "optimized implementation for lists section" by tweaking the generics for lists. I find plausible the designer of seq.el noticed that it is still much slower to do this but wanted to keep a specific generic function contract anyway. IOW, there's nothing wrong with declaring "library X is slow, but powerful". It's just that IMO it's bad to tell people to use just that library all the time for a class of jobs. > So please let's avoid such benchmarking contests here unless you want to > work on seq.el (then a bug report is a better place for discussion). > Because it has little relevance here. Last I checked, the title of this thread is still "What's missing in Elisp that makes people want to use cl-lib?". One answer among several: fast sequence functions. So, uncomfortable as the results may be (for now at least) for proponents of "seq.el only" or "seq.el first", as long as there's talk of deprecating cl-lib in favour of these alternatives, I think concrete evidence and hard numbers very much belong to this discussion. Surely much more useful than many ideological considerations about what complexity is. If they lead to an improvement of seq.el in terms of speed, so much the better. If they lead to improvement of seq.el in terms of versatility (like allowing backward traversal, key functions), even better. Finally, please note I'm not trying to bash seq.el. I think it has its place -- polymorphic sequences are great, if I ever need them -- , but its use should _also_ be discriminate, not indiscriminate. Same for your set.el idea: IMHO it's very welcome, but I think it will suffer (and gain, of course) from the same kind of tradeoffs as seq.el. Jo=C3=A3o T=C3=A1vora