[m-dev.] remaining design issues for new integer types
novalazy at gmail.com
Mon Apr 10 19:05:06 AEST 2017
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.
> 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
> 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.)
I don't mind int for the shift count. It means << and >> can shift in
either direction, consistent across modules.
More information about the developers