basil icon indicating copy to clipboard operation
basil copied to clipboard

Add sub-64-bit integer types as primitives.

Open elucent opened this issue 3 years ago • 1 comments

Basil should support integer types with widths less than 64 bits.

Similar to Go's primitive int types, I propose redefining the current Int type as a generic "best size" integer type equal to the word size of the target architecture. We'll augment this with types with explicit sizes: I propose I8, I16, I32, and I64 for brevity's sake.

Some open questions associated with this feature:

  • Should we include unsigned integers in the language? What should their semantics be (specifically w.r.t. type coercion)?
  • Is there a compelling reason to define a distinct equivalent of C's intptr_t? Word-sized Int should be equivalent to this on most modern systems - perhaps we could even specifically define Int as pointer-sized?
  • Should we consider generalizing ints for arbitrary bit-widths? I128 could have some uses. What about atypicalwidths like I7 or I50?

elucent avatar Oct 04 '21 06:10 elucent

Similar to Go's primitive int types, I propose redefining the current Int type as a generic "best size" integer type equal to the word size of the target architecture. We'll augment this with types with explicit sizes: I propose I8, I16, I32, and I64 for brevity's sake.

:+1:

  • Should we include unsigned integers in the language? What should their semantics be (specifically w.r.t. type coercion)?

They're very dangerous but offer some potentially guarantees for low-level programming. I'd actually not support them and instead case-by-case added support for the kind of situation unsigned ints were/are being used in the wild (e.g. fixed-width bit registers/maps).

  • Is there a compelling reason to define a distinct equivalent of C's intptr_t? Word-sized Int should be equivalent to this on most modern systems - perhaps we could even specifically define Int as pointer-sized?

I can't think of any compelling reason to define them distinct (and I'm pretty sure it's a solvable problem in the given highly specific case if this proves false at some point later). Many new languages do not define them distinct.

  • Should we consider generalizing ints for arbitrary bit-widths? I128 could have some uses. What about atypicalwidths like I7 or I50?

I think, I'd go for that. It has some benefits. Though admittedly it's more work which seems to be the reason I didn't see this in any modern language (the point is, that such computations are usually better suited for BigNums/arbitrary_length_numbers and not just "4x as big integers").

dumblob avatar Oct 04 '21 15:10 dumblob