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

[Zoltan Somogyi]

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.
 
> With the above library, I ended up defining constant via the foreign
> language interface and trying to make sure they were inlined.

I would say that is doing things the hard way.

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

Zoltan.