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

[Julien Fischer]

Hi Zoltan,

On Thu, 24 May 2018, Zoltan Somogyi wrote:

> On Thu, 24 May 2018 11:11:27 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:

>
>> 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.
>
> That looks like a worthwhile goal. However, it looks like it would
> require someone who wants to cast e.g. int8 to int32 to go via int.

As I said, I added them on an as-needed basis.  We should add any
missing conversions so that going via int is *not* necessary.

Not that fixed size integers are still a WIP, that's why we haven't
announced them yet.

>> 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.)
>
> I think that is a good reason for why only int64.m has a non-cast from_int
> function. I also think that using "cast" in a name to mean "there may be
> some loss of information" is fine. But I don't see those as a reason why
> there shouldn't *also* be a cast_from_int function in int64.m, clearly
> documented as being a synonym for the plain from_int function, and
> NOT involving loss of information.

I have no objection to adding such synonyms.

> My reasoning is based on my experience with working with sets
> in the Mercury compiler. We have several implementations, and they
> weren't always compatible; they had minor differences in the names
> of predicates, or some functionality was available as a predicate
> in one set module but not another. This made it annoying to change
> the representation of something from one kind of set to another.
> I am trying to avoid this kind of annoyance when a programmer
> wants to change ":- type my_type == int32" to ":- type my_type == int64".
>
>> Do you have an alernative proposal?
>
> My addition to your proposal would be: the same functionality should be
> available from all eight modules (maybe all ten, including int.m and uint.m)
> under the same name if possible, with the obvious "mutatis mutandis" changes,
> such as int8.cast_from_uint8 versus uint8.cast_from_int8, and no casts
> to and from int in int.m itself.

Agreed.

>>> Do you think you should do that, or should I?
>>
>> Let's work out what it should be first.
>
> Agreed.

If you want to go ahead and implement the above that's fine by me.

>> The diff is fine BTW.
>
> Even including the addition of cast_from_int to library/int64.m?

Yes.

Julien.