[m-dev.] for discussion: design issue for new integer types

[Julien Fischer]

Just a reminder: please ensure you have updated to rotd-2016-10-26
by Monday; I will be commiting part 2 of the uint change then.

------------------

Hi all,

There's a bunch of design issues concerning uints that need to be resolved
before the work on them can be completed.  Since many of same issues concern
the proposed fixed size integer types, I will to cover them here too.

1. What should the literal syntax for new integer types  in Mercury be?

In order to not overload the current type checker, literals for each integer
type will need to be lexically distinct.  My suggestion is that each integer
type have a distinguishing suffix.  For the fixed size integer types these
would be:

       i8, i16, i32, i64
       u8, u16, u32, u64

For int and uint, there are couple of choices:

       i, u
       iw, uw     (where w == "word sized")

The suffix would not be required literals of type 'int'.

Should the suffixes use only lowercase 'u' and 'i' or would uppercase
also be acceptable?  Or uppercase only?

As an aside: it's long since time we allowed some form of separator
between groups of digits in integer (and float) literals.  I propose
that we allow '_' between digits as in Java and C#.

2. Automatic coercion and promotion.

There won't be any in Mercury.  If you are converting between integer
types then you will be required to say so.

3. Representation of new integer types in the term type.

How should the new new integer types be represented in the term.const/0
type?

The obvious way would be:

     :- type const
         --->    atom(string)
         ;       integer(int)
         ;       big_integer(integer_base, integer)
                 % An integer that is too big for `int'.

 	;       unsigned_integer(uint)
 	;	big_unsigned_integer(integer_base, integer).
 		% An unsigned integer that is too big for `uint'.

         ;       string(string)
         ;       float(float)
         ;       implementation_defined(string)

 	;	uint8(uint8)
 	;	uint16(uint16)
 	;	uint32(uint32)
 	;	uint64(uint64)
 	;	int8(int8)
 	;	int16(int16)
 	;	int32(int32)
 	;	int64(int64).

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?

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.)

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.)

Julien.