[m-rev.] 8, 16 and 32 bit types

Zoltan Somogyi zoltan.somogyi at runbox.com
Mon Jul 3 11:39:30 AEST 2017

Attached is a partial review of the change that introduces {int,uint}{8,16,32}.
(My web based email client doesn't handle 7000 line messages well.)

Before I finish the review, I think it is important we agree on
how we should handle two issues that my partial review has found.

The first is whether the cons_ids representing the new types and the
operations on them should look like this

    ;   int8_eq
    ;   int16_eq
    ;   ...

or like this:

    ;    int_eq(signedness, int_size)

While we had one int type, there was no duplication, while we had two,
having two copies of everything dealing with it was often easier than
worrying about parameterization. But since we now have eight and will soon
have ten, I think parameterization is preferable. True, it results in slightly larger
representations, but I am pretty sure the effect will be unmeasurable
on most if not all programs. 

The second is that I believe the values of uint{8,16,32} constants should be
represented by a uint, not an int, due to the 32 and 64 bit equivalents of
"an 8 bit signed int can't represent 255".

Julien, can you tell us your reasons for choosing the representations
in the diff, as opposed to the alternatives above? Maybe there is an issue
I haven't considered.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: partial_review
Type: application/octet-stream
Size: 16813 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20170703/ee97d476/attachment-0001.obj>

More information about the reviews mailing list