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

[Julien Fischer]

Hi Zoltan,

On Thu, 24 May 2018, Zoltan Somogyi wrote:

> For review by Julien. The first part of the diff to compiler/options.m
> is not intended to be committed, at least not now.

When are you intending to commit that change?

> Julien, it seems that library/{int,uint}{8,16,32,64}.m have
> significant differences between them that I see no reason for.

The main point of difference between them will be the conversion
predicates and functions.  (When I bootstrapped the addition of fixed
size integers I added these functions on an as-needed basis so I'm not
surprised there are some inconsistencies there.)

Also, for historical reasons, there are more differences between the int
module and the others (e.g. the existence of a predicate version of abs
in the former.)  Other differences are uninentional.

(BTW, I have an upcoming change to compiler/const_prop that will add
support for compile-time evaluation of fixed size integer arithmetic.
That change requires that the order of the mode declarations for all
the affected functions to be consistent across the various int modules.)

A couple of other notes on this:

I was originally trying to avoid the situation where the various
fixed-size int modules import each other (they have to import int and
uint).  In practice, this didn't work out, so the convention is that
the signed modules can import their corresponding unsigned module but
not the other way around.

My intention with the use of the word "cast" in the conversion function
names was that it should flag that there is a potential loss of
information in the conversion (e.g. change of signedness, narrowing
conversion etc.)  That's why the int64 module does not have a function
named cast_from_int/1.  (Because you can always convert a Mercury int to
an int64 *without* loss of information.)

> Before this diff is committed, those should be fixed. (Otherwise,
> three of the operations that this diff makes into builtins won't have
> any declarations.) The way I would do it would be to pick one,
> probably uint64.m because it is the longest file, put its function
> and predicate declarations into a logical order if necessary,
> make its function and predicate definitions match the declaration
> order (using the now-commented-out option in Mercury.options),
> and then systematically change every other file named above
> to match it in terms of what functions and predicates are declared
> and defined in what order. This requires making decisions such as:
> "this function is declared as to_int in this module and as cast_to_int
> in the other module; which name should we use everywhere?".

So, currently we have:

     :- pred from_int(...) is semidet.
     :- func det_from_int(...) = ...

where the conversion is checked and fails / throws an exception
respectively if the conversion would lose information.

     :- func from_int(...) = ...
     :- func to_int(....) = ...    (although only in one spot).

where the conversion does not need to be checked.

     :- func cast_to_X(...) = ...
     :- func cast_from_Y(...) = ...

where the some information loss is possible from the conversion but
that is acceptable to the programmer.

Do you have an alernative proposal?

> Do you think you should do that, or should I?

Let's work out what it should be first.

The diff is fine BTW.

Julien.