[m-rev.] for review: make sparse_bitsets operate on uints

[Julien Fischer]

On Sun, 4 Dec 2022, Zoltan Somogyi wrote:

> Make sparse_bitset.m operate on uints.

...

> diff --git a/NEWS b/NEWS
> index e303cbddb..44a715655 100644
> --- a/NEWS
> +++ b/NEWS

...

> +### Changes to the `counter` module
> +
> +* The following type has been added:
> +
> +   - type `ucounter/0`
> +
> +* The following predicate and function have been added:
> +
> +   - func `uinit/1`
> +   - pred `uinit/2`
> +   - pred `uallocate/1`

I am in two minds about whether ucounter should live in their own module or not.
Having a separate module would allow the names of the predicate and function
that create them to be 'init' (which is the usual convention). On the other
hand, if we add a separate module for every one of these unsigned things, we
will up with a pile of module whose names beginning with the letter 'u'.

...

>  ### Changes to the `fat_sparse_bitset` module
> 
> +* The following type has had its typeclass memberships changed:
> +
> +   - The fat_sparse_bitse(T) type now requires T to be an instance of the

s/fat_sparse_bitse/fat_sparse_bitset/

> +     uenum typeclass, replacing the earlier requirement that it be
> +     a member of the enum typeclass.
> +
>  * The following obsolete predicate has been removed:
>
>     - pred `empty/1`
> @@ -123,6 +165,12 @@ Changes to the Mercury standard library
>      - pred `string_hash/2`
>      - pred `uint_hash/2`
> 
> +### Changes to the `int` module
> +
> +* The following type has had its typeclass memberships changed:
> +
> +    - The type `int` is now an instance of the new uenum typeclass.
> +
>  ### Changes to the `io` module
>
>  * The following predicates have been added:
> @@ -478,6 +526,12 @@ Changes to the Mercury standard library
>
>  ### Changes to the `sparse_bitset` module
> 
> +* The following type has had its typeclass memberships changed:
> +
> +   - The sparse_bitse(T) type now requires T to be an instance of the

Again.

> +     uenum typeclass, replacing the earlier requirement that it be
> +     a member of the enum typeclass.
> +
>  * The following obsolete predicates has been removed:

...

> index 5a1d57277..d5504b65a 100644
> --- a/compiler/make.make_info.m
> +++ b/compiler/make.make_info.m
> @@ -158,12 +158,16 @@
>
>  :- type target_file_timestamps == map(target_file, timestamp).
> 
> +% NOTE Having version_arrays be indexed by uints, not ints
> +% that just happen to never be negative, would avoid some casts
> +% from uint to int when accessing the reverse maps in the next two types.

The Mercury type used to index arrays (in both the array and version_array
modules) is constrained by how they are indexed in our target languages.  For
Java, the index type is int -- I fairly certain that for C# is the same.  (This
is one of the reasons that we map Mercury's int type on to Java/C#'s int type
instead of their long type.)

...

> diff --git a/library/enum.m b/library/enum.m
> index 273186046..9d7830935 100644
> --- a/library/enum.m
> +++ b/library/enum.m
> @@ -43,10 +43,23 @@
>      func from_int(int) = T is semidet
>  ].
> 
> +    % This is another version of the above typeclass, which maps
> +    % values of type T to *unsigned* integers.
> +    %
> +    % The other difference is that from_uint is a semidet *predicate*,

I suggest:

     ... is that the from_uint method is a semidet *predicate* ...

> +    % not a semidet *function*. This is because programmers are more likely
> +    % to expect predicates to be able to fail than functions.
> +    %
> +:- typeclass uenum(T) where [
> +    func to_uint(T) = uint,
> +    pred from_uint(uint::in, T::out) is semidet
> +].
> +
>      % det_from_int(I) returns the result of from_int(I), but throws an
>      % exception if from_int fails.
>      %
>  :- func det_from_int(int) = T <= enum(T).
> +:- func det_from_uint(uint) = T <= uenum(T).

That's fine otherwise.

Julien.