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

[Julien Fischer]

Hi Zoltan,

On Fri, 21 Oct 2016, Zoltan Somogyi wrote:

> On Fri, 21 Oct 2016 11:06:43 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
>> 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.
>
> That is correct if the function call actually gets executed at runtime.
> However, it is possible to add code to compiler to guarantee its evaluation
> at compile time. We already do this in (some of) the code generators
> for operations such as multiplications by constants, and during the
> simplification pass at the end of semantic analysis for operations
> such as string.format.

Of course, my point is that if you define these types as solely as
library types (as now) then that can't happen.  You require some
compiler / language support.

...

>> 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)
>
> I don't think anyone has ever said that would be a bad thing to do.
> All the objections have always consisted of reminders that that is
> a *hard* thing to do.

I'll grant you that there's *a lot* to do, but I suspect the hard part
may be simply working out where to do everything.  After all, it's been
a very long time since a new builtin type was added.

Julien.