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

[Julien Fischer]

Hi,

On Sat, 22 Oct 2016, Zoltan Somogyi wrote:

> On Fri, 21 Oct 2016 22:49:24 +1100, Mark Brown <mark at mercurylang.org> wrote:
>
> However, if we supported multiple integer types with the same syntax
> for literals, which would allow 2 to have as its type not just int,
> but also uint, int32, uint32, etc, the ambiguities would pile up
> pretty quickly.

We will not be able to support the same literal syntax for multiple
integer types at the moment.  Requiring a separate literal syntax for
each integer type is the compromise that is going to have to be made for
this to work with the existing type checker.  I'm fine with that
compromise, the annoyance of having to deal with foreign code written in
lanugages that do have multiple integer types in Mercury significantly
outweighs the annoyance of having to remember to add a suffix to an
integer literal.

> This is a point against similar proposals in the past; if I understand
> the current proposal correctly, it would not apply to it.

I don't think anyone had got as far as discussing the literal syntax,
but it would probably be of the from of an additional suffix (e.g. i8,
i16, u8, u16 etc.).  In the absence of a suffix the type would be
'int', as now.

I now have most of an initial diff that adds support for a new builtin
type 'uint'**.  I'll post something for review (hopefully) by the end
of the weekend.

(** any additional new builtin types would require a similar set of
changes.)

Julien.