[m-rev.] for review: make many integer casts into builtins

[Julien Fischer]

On Sat, 26 May 2018, Zoltan Somogyi wrote:

> On Thu, 24 May 2018 21:32:29 -0400 (EDT), Julien Fischer <jfischer at opturion.com> wrote:
>
>>
>> Hi Zoltan,
>>
>> On Thu, 24 May 2018, Zoltan Somogyi wrote:
>>
>>> As far as this diff is concerned, there are several possible avenues for fixes.
>>>
>>> Option A is to simply not make the third category of operations into builtins.
>>> This is simple to do, but leaves performance on the table.
>>>
>>> Option B is to make the third category of operations into builtins only if the
>>> target machine is 64-bit. This is *far* from simple to do, because it means
>>> that whether a function is a builtin or not depends on the target platform,
>>> which means e.g. that we won't know whether to reject clauses for them.
>>
>> Please do *not* do this.
>
> Actually, it was the option I thought of first. Then, after about ten milliseconds,
> I thought through the implications, and recoiled like you did :-)

You were quite slow to realize them then ;-)

...

>> This raises another couple of issues: the documentation of those
>> functions (e.g. floor_to_int etc) is not about what happens in a number
>> of edge cases (e.g. if the argument won't fit in an int or is one of
>> the special floating point values).
>>
>> The behaviour of the int->float conversion (i.e. float/1) is also
>> underspecified and prone to get a bit interesting at the edge cases.
>
> Agreed, but those are separate issues from the one under consideration.

Certainly; I just happened to look at them as when responding to this
mail.  Incidentally, the situation with them is particuarly bad as
floor_to_int(infinity) etc produces different results on the C, Java and
C# backends.

Julien.