[m-dev.] for discussion: design issue for new integer types
jfischer at opturion.com
Wed Nov 2 09:51:27 AEDT 2016
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
>> 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 to which part of the paragraph? Switching to
> "int_const(integer, signedness, maybe(size))”?
Yes, I meant that part.
More information about the developers