From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jonas Bernoulli Newsgroups: gmane.emacs.bugs Subject: bug#58278: Add new function seq-keep Date: Tue, 04 Oct 2022 14:50:28 +0200 Message-ID: <87v8ozu50r.fsf@bernoul.li> References: <87y1twtx22.fsf@bernoul.li> <87pmf84ggg.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33233"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58278@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 04 15:08:15 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ofheh-0008Oz-4s for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 04 Oct 2022 15:08:15 +0200 Original-Received: from localhost ([::1]:42878 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ofheg-0005ZB-2N for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 04 Oct 2022 09:08:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48334) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofhO3-0004LD-6M for bug-gnu-emacs@gnu.org; Tue, 04 Oct 2022 08:51:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53800) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ofhO2-0000Bq-RN for bug-gnu-emacs@gnu.org; Tue, 04 Oct 2022 08:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ofhO2-0003RP-FT for bug-gnu-emacs@gnu.org; Tue, 04 Oct 2022 08:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jonas Bernoulli Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Oct 2022 12:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58278 X-GNU-PR-Package: emacs Original-Received: via spool by 58278-submit@debbugs.gnu.org id=B58278.166488783413191 (code B ref 58278); Tue, 04 Oct 2022 12:51:02 +0000 Original-Received: (at 58278) by debbugs.gnu.org; 4 Oct 2022 12:50:34 +0000 Original-Received: from localhost ([127.0.0.1]:52878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofhNa-0003Qh-BZ for submit@debbugs.gnu.org; Tue, 04 Oct 2022 08:50:34 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:57612) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofhNX-0003QW-3e for 58278@debbugs.gnu.org; Tue, 04 Oct 2022 08:50:33 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id AD853169E4; Tue, 4 Oct 2022 14:50:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :references:in-reply-to:subject:subject:from:from:received :received; s=sel2011a; t=1664887828; bh=M9HiS5RDG7if4bliQZnv6TE5 BfqajnC+GXstWR8Gibk=; b=e+Ryyc0LdX59quNN8dylP00G1Fb8YlSpr/teIpS3 brZ5DyI6L4FWD65CBuLrdeuOHSNqgN7sGj/EVmXXiOctdLYokIb7aInh1WVr2mfV Tui5E3/iOaBWgUJi5Ta66MWQCljihVUY9c7Dtu9yTCREtwZiFWx4m1UeXwc1Fecn v58= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id nnIGFli9DYH9; Tue, 4 Oct 2022 14:50:28 +0200 (CEST) Original-Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 7F11416916; Tue, 4 Oct 2022 14:50:28 +0200 (CEST) In-Reply-To: <87pmf84ggg.fsf@gnus.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:244427 Archived-At: Lars Ingebrigtsen writes: > Would a function signature like > > (cl-defgeneric seq-keep (function sequence &optional pred) > ...) > > make more sense for this combination of map/filter? (The default > predicate would, of course, be "not null".) Yes, that would be an improvement. Some (but certainly not all) uses of dash's `-keep' look something like (-keep (lambda (elt) (and (symbolp elt) (symbol-name elt))) sequence) and (seq-keep #'symbol-name sequence #'symbolp) would be much nicer in those situations. In at least some of those cases `mapcan' would work just as well as `-keep', so after adding &optional PRED, `seq-keep' could also be used in many places one would have reached for `mapcan' before, making it even more useful. I am unsure how I feel about it myself, but we should also consider (function pred sequence) PRED wouldn't be optional then, but we should of course allow it to be nil. (Forcing the use of #'identity would not make sense, since we want FUNCTION to serve both as a predicate and a transforming function in that case.) Concerning the argument order, in my opinion (seq-keep (lambda (elt) ...) (lambda (elt) ...) sequence) looks better than (seq-keep (lambda (elt) ...) sequence (lambda (elt) ...)) because the variable named "sequence" looks out of place in the second instance. But of course all of FUNCTION, PRED and SEQUENCE can be just a symbol or a more complex expression. For instance if only PRED is complex, then (seq-keep #'symbol-name sequence (lambda (elt) ...)) looks better than (seq-keep #'symbol-name (lambda (elt) ...) sequence) So there is no order that is always best, from an aesthetic point of view. In my own use at least, most of the time either all three arguments would be moderately complex expressions or only the two functions arguments would complex and the sequence argument would be just a variable. For that reason I would favor the two functions to be placed next to each other, I think. The (function pred sequence) argument list has the advantage that it is in (reverse) "chronological" order. First we have a sequence, then we filter the elements, and finally we transform the elements that we kept, at least conceptually. Using actual chronological order (sequence pred function) is out of question as that would conflict with all(?) other mapping functions; as is (sequence [pred] function), I presume. Just some food for thought; as of yet, I am unsure what order I prefer myself -- though I lean towards (function pred sequence). But if that is deemed unusual and thus undesirable, (function sequence &optional pred) also works for me.