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

[Mark Brown]

On Fri, Oct 21, 2016 at 7:33 PM, Zoltan Somogyi
<zoltan.somogyi at runbox.com> wrote:
> On Fri, 21 Oct 2016 17:17:17 +1100, Mark Brown <mark at mercurylang.org> wrote:
>> Backend compilers are likely to be able to statically evaluate expressions like
>>
>>     (123 * 1000 + 456) * 1000 + 789
>>
>> to get the number 123456789. Can we get enough inlining of the library
>> functions to generate code like this, or at least something that
>> backend compilers can statically evaluate?
>
> You don't need to *inline* a library function if you are willing to make
> its semantics static enough, which would be a given if the function is
> a part of the definition of a builtin type. That is because in that case,
> you can bake the semantics of the library function into the compiler's
> builtin_ops.m and const_prop.m modules.

Sure, but my comment was in reference to the new types being solely
library types, which I take to mean that they are not builtin. I'm
asking whether this is a good workaround - even when speed is critical
- until the literals and baked-in semantics can be added to Mercury.

Mark