From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: master 4b79c80c999 1/2: New function 'sort-on' Date: Fri, 02 Feb 2024 17:05:33 +0100 Message-ID: <87y1c2hmwi.fsf@daniel-mendler.de> References: <170688047526.14693.2994051491358257471@vcs2.savannah.gnu.org> <20240202132756.4272CC0EFE7@vcs2.savannah.gnu.org> <87cytej4hy.fsf@daniel-mendler.de> <86zfwi52m1.fsf@gnu.org> <87a5oij399.fsf@daniel-mendler.de> <86y1c250m0.fsf@gnu.org> Reply-To: Daniel Mendler Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20699"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 02 17:06:53 2024 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 1rVw44-00054K-Qv for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Feb 2024 17:06:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rVw3C-0000IN-5A; Fri, 02 Feb 2024 11:05:58 -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 1rVw39-0000Hy-S2 for emacs-devel@gnu.org; Fri, 02 Feb 2024 11:05:55 -0500 Original-Received: from server.qxqx.de ([2a01:4f8:c012:9177::1] helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rVw37-0005ug-T7; Fri, 02 Feb 2024 11:05:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zlHuUD4wOHtsrkDbBRjrkLbAQtu6Y+JIWR2VJe3MDEA=; b=Afh7PVZrvPU8JFvLquzhLUMBut yt1oVguLubpaKmKwtBZpJGbcB1+qSUsm+qFp832GYM7XPnQdGTY0APuQh/zi4gGN1B90bw0UVJErc RBFPloDs9wuYjVAEcbQTPg7+pHaADzp05xAGkt7iOup0RTx/EoGwmNF4oxljNpGfBlPs=; In-Reply-To: <86y1c250m0.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 02 Feb 2024 17:47:51 +0200") Received-SPF: pass client-ip=2a01:4f8:c012:9177::1; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de 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, SPF_HELO_PASS=-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:315762 Archived-At: Eli Zaretskii writes: >> From: Daniel Mendler >> Cc: emacs-devel@gnu.org >> Date: Fri, 02 Feb 2024 16:26:58 +0100 >> >> Eli Zaretskii writes: >> >> >> Would this function fit into the seq library, named seq-sort-on? >> > >> > "Fit" in what sense? >> >> The function works with other sequence types too and it seems a good >> idea to collect sequence-related functionality in seq.el. > > OK, but the result is always a list, something seq.el doesn't do. Right. Seq functions usually return sequences of the same type as the argument type. I've found one exception though: `seq-keep' always returns lists. Maybe `seq-keep' should be corrected? I propose to generalize `sort-on' to other sequence types. >> > This function can only sort lists, so at least from that aspect its >> > place is not in seq.el. In addition, I see no reason to have it >> > preloaded. >> >> No, in the current form, the function works on vectors too. It always >> returns a list though. But maybe it makes sense to generalize it such >> that it returns the same type as the argument. > > I see no reason to preload this function, anyway. Agree, this is certainly a reason. However if the function is general and useful enough, this should not prevent making it part of seq.el. There have been additions to seq.el in the past. Of course each addition has to be considered carefully. The same applies to additions to subr.el. >> > I've put it in sort.el because the function 'sort' is there. >> >> No, sort is defined in src/fns.c. > > And your point is...? My point is that sort.el is not the ideal place for this function. As Michael mentioned, sort.el provides commands to sort lines, paragraphs and other units of text in buffers. In contrast, new `sort-on' function is a small library function, so it should better be added to subr.el or subr-x.el, or with a different name to seq.el. Daniel