[m-rev.] for post-commit review, and a proposal: sparse_bitsets

[Julien Fischer]

On Wed, 30 Nov 2022, Zoltan Somogyi wrote:

> The proposal is to add a new typeclass to enum.m.
> At the moment, we have this one:
>
> :- typeclass enum(T) where [
>    func to_int(T) = int,
>    func from_int(int) = T is semidet
> ].
>
> The proposal is to add this one:
>
> :- typeclass enum_uint(T) where [
>    func to_uint(T) = uint,
>    pred from_uint(uint::in, T::out) is semidet
> ].
>
> The diff explains why the new typeclass would be better
> for sparse bitsets, and probably for other applications as well.
> In most and maybe all of our use cases, the to_int function
> never returned any negative numbers anyway, so switching
> uses of sparse_bitsets in the compiler to a version using
> this typeclass would be trivial.
>
> Would anyone object to
>
> - adding the new typeclass,
> - its switch from a semidet function to a semidet predicate, or
> - switching {fat_}sparse_bitset.m to using the new typeclass?
>
> The last would be an incompatible change, but we could mention in NEWS
> that users could replace any to_int function with a to_uint function like this:
>
> to_uint(Item) = UInt :-
>  Int = to_int(Item),
>  ( if Int < 0 then UInt = (-Int) + 1 else UInt = from_int(Int) * 2 ).
>
> This represents negative ints as odd uints and non-negative ints
> as even uints.

I have no objection to any of the above.

> And does anyone have a better name than enum_uint?

There's a broader issue to consider here: if we have something that
works with ints and we add a version that uses uints, how should those
new somethings be named in general. I think there should be a consistent
convention for this across the standard library.

One possibility is to just prefix the names of the unsigned versions of
things with "u", e.g. uenum, ulength etc.  That has the advantage of
being short and easily memorable.

Julien.