Received: (at 79844) by debbugs.gnu.org; 17 Nov 2025 12:23:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 17 07:23:40 2025 Received: from localhost ([127.0.0.1]:51005 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vKyGi-0002U2-Cj for submit <at> debbugs.gnu.org; Mon, 17 Nov 2025 07:23:40 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46622) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vKyGf-0002TZ-Rj for 79844 <at> debbugs.gnu.org; Mon, 17 Nov 2025 07:23:38 -0500 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 <eliz@HIDDEN>) id 1vKyGX-00058W-Hm; Mon, 17 Nov 2025 07:23:29 -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=l1pJRyCves7UsHwrP89Cui2QK+jVZ83IKFoFST3RnAw=; b=HSsz2mHU4VtExIM/pz0p rIq+uA/4EqC/WvX9NRNGTRpXrZT/w/2cl5W9o54MC9wtm75qQJT/ykL8jeNKP4CEmjLGWXJXNXiAG cRrGh66y+Rm3aNy7wIpteepUQTS7zO6M11nj9jcuYVKicFy5JJ4easAg5uOLzmzGyx/tT0E7zpVdM QCIVjg4fN17L4WgWm8O8AxyyFluATUUZ77Yc+T6B2O+oD0yYUX9ddKbv4OAJ0Oq/LyhjaHwWcOmzx nWJMtDYClddF9YZbNc7fo4jTtq5HEXcgE5RBibnMQFxVyTLfgRQCrkMvXhgV9YqcNDb+nc8e7YWZf 7T8A8OoHL6J0Iw==; Date: Mon, 17 Nov 2025 14:23:27 +0200 Message-Id: <86pl9gluf4.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Arsen =?utf-8?Q?Arsenovi=C4=87?= <arsen@HIDDEN>, Nicolas Petton <nicolas@HIDDEN>, Stefan Monnier <monnier@HIDDEN> In-Reply-To: <86tsyu2dcw.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#79844: 31.0.50; Documentation: seq-intersection does not specify the resulting sequence order References: <86tsyu2dcw.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79844 Cc: 79844 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sun, 16 Nov 2025 16:42:23 +0100 > From: Arsen Arsenović via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > The documentation of seq-intersection is: > > Return a list of all the elements that appear in both SEQUENCE1 and > SEQUENCE2. "Equality" of elements is defined by the function TESTFN, > which defaults to ‘equal’. > This does not modify SEQUENCE1 or SEQUENCE2. > > ... but this does not specify what order the resulting sequence will be. > For set operations, this makes sense, as sets are unordered. But this > function can be used on lists, which are ordered. > > The current (and only) implementation is written in a way that retains > the order of SEQUENCE1, i.e. > > (seq-intersection '(b c) '(c b a)) > > .. is always '(b c), but I don't see a guarantee of this. > > Is that intentional behavior (seems so - I see a seq-reverse in there, > which one would have no need for if the order didn't matter)? If so, > could we document it? > > If not, could we document that the order is unspecified and provide a > new function that specifies that SEQUENCE1 order is kept? If the order of the elements in the result is not documented, doesn't it already mean that it's unspecified? As for providing a new function: that can be done, but what to do about sequences where the notion of order doesn't exist to begin with? I'm interested to hear what others (including the author of the package) think about this.
bug-gnu-emacs@HIDDEN:bug#79844; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 16 Nov 2025 15:42:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Nov 16 10:42:41 2025 Received: from localhost ([127.0.0.1]:45817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vKetl-0000uP-4S for submit <at> debbugs.gnu.org; Sun, 16 Nov 2025 10:42:41 -0500 Received: from lists.gnu.org ([2001:470:142::17]:39810) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <arsen@HIDDEN>) id 1vKetj-0000u9-0E for submit <at> debbugs.gnu.org; Sun, 16 Nov 2025 10:42:39 -0500 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 <arsen@HIDDEN>) id 1vKetc-00008n-Lx for bug-gnu-emacs@HIDDEN; Sun, 16 Nov 2025 10:42:32 -0500 Received: from mout-p-102.mailbox.org ([2001:67c:2050:0:465::102]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from <arsen@HIDDEN>) id 1vKetb-0000Rq-47 for bug-gnu-emacs@HIDDEN; Sun, 16 Nov 2025 10:42:32 -0500 Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4d8ZrL1Ktmz9tSS for <bug-gnu-emacs@HIDDEN>; Sun, 16 Nov 2025 16:42:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1763307746; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=5VvAG4b2o6FjzWhuWXdoqUC4bu2q96kdg74RPS8C9DA=; b=p5+hHMgN3ebTk5YQgIPbicKhxbcx72fTHGhBMM+ZBHNdgLblMN7XCkMNVz/zVa7ii/puCy x8m5cwNSGkDane43UehCOVCHsGvqwfHSvdWKbhKmUH9RLvNJu0S8XUAyzA1Ax0zjzwv1iL wUiSQJZvf2hSywxUEVfNLOslSyeT6kPBT2oPB/ZQbawAxNXaYY8ktrVFwzQRkf8o1qT+XO jmPlSEKp6tTH3V4BF2nMf13/u1hOoJ3cMSy7bbHc8BHz3ZxFIh0IhNcSPMTAwFVBZ9t2XM NmNw7H3Y6annmjzbK6fWdeU3YF6PG/kIkvI7Qdd+iSPUI5pDEk23ZqJvTzTdhQ== From: =?utf-8?Q?Arsen_Arsenovi=C4=87?= <arsen@HIDDEN> To: bug-gnu-emacs@HIDDEN Subject: 31.0.50; Documentation: seq-intersection does not specify the resulting sequence order X-Debbugs-Cc: Date: Sun, 16 Nov 2025 16:42:23 +0100 Message-ID: <86tsyu2dcw.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=2001:67c:2050:0:465::102; envelope-from=arsen@HIDDEN; helo=mout-p-102.mailbox.org 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 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.3 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, The documentation of seq-intersection is: Return a list of all the elements that appear in both SEQUENCE1 and SEQUENCE2. "Equality" of elements is defined by the function TESTFN, which defaults to =E2=80=98equal=E2=80=99. This does not modify SEQUENCE1 or SEQUENCE2. ... but this does not specify what order the resulting sequence will be. For set operations, this makes sense, as sets are unordered. But this function can be used on lists, which are ordered. The current (and only) implementation is written in a way that retains the order of SEQUENCE1, i.e. (seq-intersection '(b c) '(c b a)) .. is always '(b c), but I don't see a guarantee of this. Is that intentional behavior (seems so - I see a seq-reverse in there, which one would have no need for if the order didn't matter)? If so, could we document it? If not, could we document that the order is unspecified and provide a new function that specifies that SEQUENCE1 order is kept? TIA, have a lovely day. =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQECBAEWCgCqFiEE/uKz0RP8AKMWLWBhUsKUMB6ixJMFAmkZ8N8bFIAAAAAABAAO bWFudTIsMi41KzEuMTEsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRUUyQjNEMTEzRkMwMEEzMTYyRDYw NjE1MkMyOTQzMDFFQTJDNDkzEBxhcnNlbkBhYXJzZW4ubWUACgkQUsKUMB6ixJMN 5AEA+CcKTXWGOZ1/ORVS2m7BusRLBg/Mv9e2WiNtiOohGfkBAOqOvmP+k8iZ+Eid HRmuoEAtKgHxUuABc1u6vkhBp9YP =Xqa7 -----END PGP SIGNATURE----- --=-=-=--
Arsen Arsenović <arsen@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#79844; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.