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

[Mark Brown]

Hi,

On Fri, Oct 21, 2016 at 2:56 AM, Julien Fischer <jfischer at opturion.com> wrote:
>
>>>> +    % The behaviour is undefined if overflow occurs.
>>>
>>>
>>> The only reason it is "undefined" is because in the C grades you can't
>>> necessarily assume two's complement arithmetic; I'm not aware of Mercury
>>> running on any system that doesn't use two's complement arithmetic**, so
>>> perhaps we should just require that Mercury ints use two's complement
>>> representation and define these operations to wrap.
>>>
>>> (** in the event of there being such a system we would just have to
>>> implement the wrapping behaviour.)
>>
>>
>> I think the reason it is undefined is the comment at the top of the
>> module: reserving the right to check for overflow in the future.
>
>
> Maybe, I'm not sure what the original author had in mind!

As I recall, the main factor was that even if it were defined it would
still be platform dependent because it depends on the word size. It
was thought better just to say "the usual caveats apply when using
int" than to provide complete definitions.

That decision is from the '90s, though. I have no problem with taking
Julien's approach now.

> 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 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?

Mark