[m-rev.] for review: ulength/ucount

[Julien Fischer]

On Fri, 2 Jan 2026 at 05:58, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
> For review by anyone. The main things I am seeking feedback on are
> these:
>
> - For the set modules, some define count as both a func and as a pred, while
>   some others define it only as a func. Should we add pred versions as well?
>   This could cause compatibility issues, due to issues with "which version
>   did I just curry". But then, the gratiutous differences between
>   otherwise-compatible modules can also be annoying.

Or we could just remove the pred versions, since the modules that provide
that are in the minority anyway.  Removing the difference is good, I'm not
particularly bothered about which way it is done.

> - I added to set.m a list of all the modules that implement sets. I can add
>   something similar to map.m and to list.m,

I think a brief addition to the top of map.m and list.m would be useful.

> but I am on the fence about
>   whether we should instead add a central file listing all the groups of
>   related modules.

I don't want to add an extra file just to hold documentation, although library.m
could contain it.  The other choice would be to add an overview section
to the library reference guide.  (Or indeed both.)

This would allow better treatment of e.g. arrays
>   (which are sort-of maps whose keys are integers, just as sparse_bitsets
>   are sets whose values are integers) and their versioned cousins.

Because of the uniqueness, arrays and data structures based on them
(e.g. hash tables) are not that easily interchangeable with maps (at least
not in the same way that many of the set implementations are).

> Opinions?
>
> BTW, before commit, I intend to fix the out-of-order entries of the
> one_or_more/one_or_more_map modules in NEWS.md.

The diff is fine.

Julien.