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

[Julien Fischer]

Hi Zoltan,

On Tue, 11 Apr 2017, Zoltan Somogyi wrote:

>
>
> On Mon, 10 Apr 2017 13:46:10 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
>>      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?

...

I'll comment on the format stuff in a separate mail.

>>      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.)
>
> At the moment, int.m provides reverse modes for only two operations, + and -.
> (The reverse modes of the multiplicative operators are complicated by the
> potential non-zero values of remainders.)
>
> I think providing reverse modes of these predicates should be trivial
> (they can just call the forward mode of the appropriate operations),
> and that providing them can avoid hassles when e.g. changing a type
> from int to int16. I therefore think we should provide them.

Ok, I've begun adding support for these.

>
>>      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.)
>
> The problem is that the right domain for the shift amount is [0 .. NB),
> where NB is the number of bits in the type.
>
> The question we need to answer first, before answering your question, is
> "is the current behavior of int.<< and int.>> what we want?". My answer is
> that I don't think so. I think both should throw an exception if the shift
> amount sa satisfies either sa < 0, or NB =< sa.

Agreed.  (That's what I did in the inttypes library.)

> At the moment, we don't throw on either condition. For sa < a, we switch
> the shift direction, and for NB <= sa, we just return a constant result
> (either 0 or -1). Testing whether we want to throw an exception could be done
> in C with one test: NB =< (unsigned) sa.
>
> Making the shift amount unsigned removes all values less than zero, but still it
> leaves all the values at or above NB. The above test would work for both; it's
> just that the cast is redundant for one.

In that case, I think it would be best to say that the second operand of all
shift operators for all integer types has type 'int'.

> (If we made the operation of int.<< and int.>> stricter than it is now, we would
> have to announce it,

I'm happy to make the definitions of int.>> and int.<< stricter; does anyone
have any objections?

> and provide the old behavior in predicates with other names.)

Is your intention to deprecate these versions, or simply preserve them
under a different name?

Julien.