GNU logs - #79844, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#79844: 31.0.50; Documentation: seq-intersection does not specify the resulting sequence order
Resent-From: Arsen =?UTF-8?Q?Arsenovi=C4=87?= <arsen@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Nov 2025 15:43:01 +0000
Resent-Message-ID: <handler.79844.B.17633077613504 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 79844 <at> debbugs.gnu.org
From: Arsen =?UTF-8?Q?Arsenovi=C4=87?= <arsen@HIDDEN>
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-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-----
--=-=-=--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Arsen =?UTF-8?Q?Arsenovi=C4=87?= <arsen@HIDDEN>
Subject: bug#79844: Acknowledgement (31.0.50; Documentation:
 seq-intersection does not specify the resulting sequence order)
Message-ID: <handler.79844.B.17633077613504.ack <at> debbugs.gnu.org>
References: <86tsyu2dcw.fsf@HIDDEN>
X-Gnu-PR-Message: ack 79844
X-Gnu-PR-Package: emacs
Reply-To: 79844 <at> debbugs.gnu.org
Date: Sun, 16 Nov 2025 15:43:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 79844 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
79844: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D79844
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#79844: 31.0.50; Documentation: seq-intersection does not specify the resulting sequence order
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 17 Nov 2025 12:24:02 +0000
Resent-Message-ID: <handler.79844.B79844.17633822209555 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Arsen =?UTF-8?Q?Arsenovi=C4=87?= <arsen@HIDDEN>, Nicolas Petton <nicolas@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
Cc: 79844 <at> debbugs.gnu.org
Date: Mon, 17 Nov 2025 14:23:27 +0200
Message-Id: <86pl9gluf4.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <86tsyu2dcw.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
References: <86tsyu2dcw.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> 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.

Last modified: Mon, 17 Nov 2025 12:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.