GNU bug report logs -
#69709
`sort` interface improvement and universal ordering predicate
Previous Next
Full log
Message #77 received at 69709 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Fri, 29 Mar 2024 11:59:39 +0100
> Cc: Dmitry Gutov <dmitry <at> gutov.dev>,
> Eli Zaretskii <eliz <at> gnu.org>,
> 69709 <at> debbugs.gnu.org,
> Gerd Möllmann <gerd.moellmann <at> gmail.com>
>
> 25 mars 2024 kl. 12.11 skrev Mattias Engdegård <mattias.engdegard <at> gmail.com>:
>
> > The plan is to add scratch/sort-key to master in a few days if no serious issues turn up.
>
> Plan executed.
Thanks.
I have a few comments/questions about value<:
. The description of value< says "lexicographic order" about some
types, but I think that is not clear enough, and we should tell
explicitly how the comparison works in those cases. AFAIU, the
corresponding elements are compared by recursively calling value<
for them? And what happens if one has more elements than the other?
These are all questions that popped up when I read the new text,
and I think they should be answered in the text.
. AFAICT, no ordering is defined for overlays, and I wonder why. I
think this could be very useful; we certainly sort overlays in C in
several places.
. Various fine details about value< are never mentioned: the fact
that there's a limit to recursion, the special treatment of nil in
some cases, etc. I think we should document them, at least in the
doc string if not in the manual as well.
This bug report was last modified 1 year and 89 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.