[m-dev.] remaining design issues for new integer types

[Peter Wang]

Hi Julien,

On Mon, 10 Apr 2017 13:46:10 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> 
> Hi all,
> 
> There were a few left-over issues from the discussion about the
> the new integer types last October.
> See: 
> <http://lists.mercurylang.org/archives/developers/2016-October/016639.html>
> 
> In particular, the last three points:
> 
>      4. poly_type and format.
> 
>      * Should string.poly_type include an alternative for uints and
>      be supported by io.format etc?
>      * What about the fixed size integers?

It must be possible to format integers wider than int, and to format
uint without using something like cast_to_int, so I say yes.

> 
>      5. Reverse modes of arithmetic operations.
> 
>      The int module currently provides reverse modes for operations like (+).
>      uint currently doesn't, should it?  (We don't currently provide them for
>      arbitrary precision integers either.)

If the mode exists for int, the reason for it should apply to the other
types.

> 
>      6. What type should the second operand of the left and right shift operations
>      be?
> 
>      Should it be:
> 
>            uint >> uint = uint    (as in Peter's version of the uint module)
>            uint >> int = uint     (as in my inttypes library)
> 
>      (The justification for the latter in the inttypes library was that we didn't have
>      literals for the various types.)

I don't mind int for the shift count.  It means << and >> can shift in
either direction, consistent across modules.

Peter