[m-rev.] for discussion: undefined behaviours in int.m

[Julien Fischer]

Hi Mark,

On Fri, 21 Oct 2016, Mark Brown wrote:

>> I have been working on similar support for various fixed sized int types as
>> a
>> library, see: <https://github.com/juliensf/mercury-inttypes>.  Based on
>> that, I
>> think you would need to extend the language to at least support 'uint'
>> literals
>> as well -- their absence makes things quite awkward.
>
> I'd like to see this in the Mercury standard library, even if literals
> aren't immediately available.

I assume that's in addition to the 'uint' (i.e. word sized unsigned
integer) type, rather than instead of?

I have no objections to including it, although it would require an
Erlang implementation in order to be included in the standard library
(even if that "implementation" just aborts if you try to use those
types).

> I suppose you could always make use of a
> faux- comma separator, so that for example ten billion could be
> written as int64([10,000,000,000]). Passable?

It depends on what you (and indeed the compiler) are doing.  Defining
a constant via a function call would be undesirable in speed critical
code.

With the above library, I ended up defining constant via the foreign
language interface and trying to make sure they were inlined.
(That's not a great solution though since I have an increasing amount
of code that has to work with both the C and Java backends and that
means every constant requires two foreign_proces.)

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

As a longer term goal, are there any objections to extending Mercury
so that it supports a broader range of builtin numeric types (something
along the lines of what's available in Rust, Swift, Go etc ), namely:

     - int8, int16, int32, int64
     - uint8, uint16, uint32, uint64
     - int, uint (i.e. word sized types)
     - float32, float (float64)

Julien.