[m-dev.] for discussion: design issue for new integer types

[Julien Fischer]

Hi Zoltan,

On Sun, 30 Oct 2016, Zoltan Somogyi wrote:

> My use of “require” was the wrong word. As I thought my next paragraph
> made clear, I was thinking only about a warning, and only if the
> programmer explicitly *asked* for it.
>
>>> We would need to delete the _s at some point anyway. If we do it
>>> in the compiler, we can make the coding doing the deletion
>>> generate a warning if the _s are in the "wrong" place, with the
>>> notion of "wrong" being selected by compiler options such as
>>> --warn-misplaced-integer-underscores-{western,indian}.
>>
>> I don't think that's something the compiler should be concerned with
>> (except possibly in the formatting of error messages).
>
> What is the “that” the compiler shouldn’t be concerned with?
> Generating warnings, or deleting the _s?

By "that" I mean generating the warnings.

...

>> Yes.  The existing numeric types (int, float, rational, integer) already
>> define these sort of coercions; with the new types there's just going
>> to be a lot more of them.
>
> With N integer types, there will need to be N*(N-1) coercion functions.
> I guess N is just low enough for that to be manageable.
>
> Do you propose to avoid a further multiplication by two by allowing
> just one, not both, of e.g. int8_to_int32 and int32_from_int8?

In short, yes.  Looking at the current standard library, the whole issue
of what coercion functions we provide and were they live is a bit more
complicated than I initially thought and probably best discussed in a
separate thread (and in the presence of a concrete proposal, which
I will write up).

>>> I would instead suggest that we keep just the existing
>>> integer and big_integer functors, and add a new argument to both.
>>> This argument would say int vs uint, and 8 vs 16 vs 32 vs 64 vs
>>> default size, *purely on the basis of the suffix, without any check
>>> in the scanner*, for reason given above.
>>>
>>> To allow the underscore check mentioned above, the existing argument
>>> of the integer and big_integer functors would need to be a string,
>>> with the conversion done in the compiler. However, doing that
>>> would erase the need for the big_integer functor, since the integer
>>> functor would then be able to represent everything it can.
>>
>> I prefer the second scheme.
>
> Do you mean the one in the paragraph that starts with “To allow the
> underscore …”?

Yes, I mean the proposal that stores the number as a string and erases
the need for the big_integer functor.

>>> I would even prefer to erase the distinction between int_const and
>>> uint_const, but realize that this cannot be done, because in the HLDS, we
>>> definitely want the constant in integer, not string, form, and there is no
>>> word sized type that can hold both all ints and all uints. However, we could
>>> switch to int_const(integer, signedness, maybe(size)).
>>
>> Ok.
>
> Ok to which part of the paragraph? Switching to
> "int_const(integer, signedness, maybe(size))”?

Yes, I meant that part.

Julien.