[m-dev.] remaining design issues for new integer types
jfischer at opturion.com
Tue Apr 11 16:19:03 AEST 2017
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
>> 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?
More information about the developers