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: Thu, 16 Nov 2023 14:57:04 +0000 Message-ID: References: <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> <87fs172i62.fsf@gmail.com> <87y1ey1zn9.fsf@gmail.com> <875y21kbnz.fsf@gmail.com> 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="23289"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Michael Heerdegen , emacs-devel@gnu.org, Dmitry Gutov To: Augusto Stoffel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 16 15:55:06 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 1r3dlq-0005uq-Kn for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Nov 2023 15:55:06 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3dl2-0004y5-0p; Thu, 16 Nov 2023 09:54:16 -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 1r3dl1-0004xu-0l for emacs-devel@gnu.org; Thu, 16 Nov 2023 09:54:15 -0500 Original-Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r3dkz-0006UT-3B; Thu, 16 Nov 2023 09:54:14 -0500 Original-Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-507be298d2aso1148473e87.1; Thu, 16 Nov 2023 06:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700146451; x=1700751251; 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=gpLnF8fi/XG94/hUapCMT0JLtjeUsunumpIhf2IFDXA=; b=Y2WuzULUpiUUjhFGnXbxNsBL3hNmoluWbdN+kjglEEiZR3BGWU9at9hpSIHZMK62pq ZqsDggjuCZu5BlRL5GnBNVOGaKy4EKyF4dz/Lt5OWy80Fk2no4b+dOj/PhUMHGrBkg8q 6jVjtS2iflFRZLTdYJc72Y+tSWgc13ogeHPn6uGCudZ27hjRUzQf6kngeCz4yV7E3bY7 nhYsMDpfGuOxvBELtq+PFSU/Alzei062/QE9F110vdu/JU7wqqUYmRIzRFXcd2Nb2wqG Nk4k0UJ4YhTKE0a4mg1CR7+PGNQ1XcokQibcWI0sIbyOwX3vQeIf+XBPfeTdKqR5T453 2fkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700146451; x=1700751251; 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=gpLnF8fi/XG94/hUapCMT0JLtjeUsunumpIhf2IFDXA=; b=Uvn+IbcNqI3p/BXKmPaZbS2ZtuXgxwnVj/rrj4ECIJvHWH81odIs70TP40kRWW0wKR vwtUyN9uYMVZ+Wxmk6bzIjrjdBid0XMh3Z7/+l+1cqTf6UyTittpZVrbp8VLiMan/+88 Yn/+pH9uh6f+4sxrAOkT+0WR2lnYtMIEpVekX4/yUQqoAhzhh22Sx+qNcCEqQeEUPzvi jFajiwZflI5TmnzJ23wGO6mexvLddph1tqquNwqMeBTIipkl0KAF9/8BhiHo9O3GhdHi 2HUr1b3jb0K8k2zX5EBEf7h4xdt31qVtYmP6bYAUZvXVa0avQnStQeB4Ur4cX+7F42Ha n38g== X-Gm-Message-State: AOJu0Yx4R5jIrJGUj5dBlNlKEBwoOx0hFajv9JSiuUzHtRuP4WI0lJC3 cG51aoDiPJRkYgsXU8t+WuI3pnpW9nI1za8cK0tQzf7AaxE= X-Google-Smtp-Source: AGHT+IH6pVkC5B0+55qDOSU5/OFK2pSa2JWlRNWl+iTC2tN3wUEqqtWMW5uPThpcMKkH9OWxiOk6apxfROupcEQsMVU= X-Received: by 2002:a05:6512:4025:b0:50a:763f:ecf1 with SMTP id br37-20020a056512402500b0050a763fecf1mr14743514lfb.12.1700146450605; Thu, 16 Nov 2023 06:54:10 -0800 (PST) In-Reply-To: <875y21kbnz.fsf@gmail.com> Received-SPF: pass client-ip=2a00:1450:4864:20::136; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x136.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:312799 Archived-At: On Thu, Nov 16, 2023 at 2:36=E2=80=AFPM Augusto Stoffel wrote: > > On Thu, 16 Nov 2023 at 00:28, Jo=C3=A3o T=C3=A1vora wrote: > > > I don't think you just skip the seq-do generic like that :-) > > Of course you don't. This _is not_ a patch submission :-). > > What I'm pointing out is that the seq-doseq macro is probably the most > consequential bit regarding performance. If you use a mapc and closures > where you could use a simple dolist, performance will obviously suffer. > > There exist extensible macros in Emacs (such as pcase), so adding some > kind dynamic dispatch for seq-doseq should be possible. Barring that, > one would have to define list-specific methods for 8 generic functions > that use seq-doseq, which is also not unfeasible. > > > That breaks any sequence type based on lists. This is exactly the > > problem I was raising with too-many-generic interfaces, btw. > > Good point. IMO you just can't have both lists and "types based on > lists" to work together properly; if we defined a method for > seq-difference on lists, the issue would be the same (I guess that's the > caveat you raised regarding Dmitri's patch). > > I don't see much appeal in user-defined seq types (as opposed to dealing > uniformly with lists, vectors and strings, which is mildly useful). User-defined sequences _are_ useful in certain problem domains. Generators, streams, lazy sequences, these are all great things. But in bread-and-butter Lisp (LISt Processing ;-) ) we don't need them indeed. And we should absolutely use the fastest library we have. seq.el can hardly be it, even if you do that shortcut (and effectively outlaw a big class of custom sequences, presumably the thing seq.el is good at). > In > any case, the user always has the options to wrap a struct or class > around their custom list types. So "sequence types based on lists" > could just be disallowed (I suppose this was part of those long > discussions, which I admit I didn't follow closely.) Yes, exactly. And sure yes, but in many cases the lingering performance overhead of generic functions still remains, unless you go all the way to the entry point and break compatibility there too. See my latest benchmarks i sent in the Dmitry thread. > > Try Dmitry's patch instead, the one containing seq-difference-3. > > That approach is fine, but it only addresses one function at a time. > (If we go that way, I suggest starting by the most useful ones: > seq-filter, seq-some and seq-reduce.) Feel free to start your branch from feature/cl-lib-improvements and keep posting benchmarks. > As far as names are concerned, cl-remove-if-not is uglier than > seq-filter. Ha, this one haunts me from the early 2000's "filter" for me personally has, for as long as I remember, been a pain in the brain. I can never tell if is is meant to keep things that verify a predicate or throw away such things. I still can't, I always have to look it up. like: "filtering coffee" leaves the bad stuff behind. "filtering Yukon river water" leaves the good stuff behind (gold). So while I have to agree that cl-remove-if-not is a pain to type, it's very clear as to what it does when you read it. Have long argued it should have been called "keep-if" though. > > cl-some vs seq-some > > cl-every vs set-every-p > > cl-set-difference vs seq-intersection > > cl-set-difference is an operation on lists, not sets... So is seq-intersection. Also not on sets. > > What specific thing do you like in seq.el that you don't > > find in the sequence functions of cl-lib.el? > Like other people already said, it's more about what you _don't_ find in > seq. The seq API is much more straightforward than cl-lib's. See my message to Dmitry. You think the super-special seq-remove-at-position is a good replacement for the much more versatile cl-remove? Bah. But hey, if it weren't for the performance aspect I would absolutely surely 1000% not mind you using seq.el in your code or in Emacs. Jo=C3=A3o