Proposal: handling uint16, usize, etc

General
1

Should we handle usize, uint16, etc? Would it be
wise to annotate number literals with a subtype indicator?

2

Yes. I think for many applications bit size is important. I’m personally a fan of this style:

  • uint
  • int
  • u32
  • i32
  • f32

etc.

2 Likes
3

i dont think usize would be useful on scrapscript. scrapscript clearly desires some form of machine-independence, and usize is only relevant for machine-specific things (pointer size). considering that there are no pointers in scrapscript, there’s no pointer-size dependent math to be done in applications themselves, no?

1 Like
4

While generally I agree, pointers and int/uint are different types in most languages and different semantics and usage patterns. I typically use int/uint when I don’t particularly care about the binary representation of the variable and want to let the system decide.

There’s 2 paths IMO: int/uint are always 64-bits and you keep the bit-specific types (ex. i32), or you make int/uint variable length integers and support a full numeric tower (ie. with “big integer” support) and drop the specific width types entirely.

5

i feel like sized types are definitely too useful to not have them. having sized ints lets us deal with stuff like Protobuf and other binary schemas and parsing things.

another approach is to have a generic ‘numeral’ type and allow the system to infer what specific type it should be based on suffix and size. have it always infer the smallest possible size for that expression. this is the approach stuff like zig and odin takes, i believe?

i think it would be best to avoid Javascript’s ‘everything is a float’ or python’s ‘everything is a bigint’, because both of these have undesirable consequences: ‘everything is a bigint’ in particular leads to things slowing to a crawl with numerics, which we may want. i believe common lisp provides transparent runtime promotion to bigints from sized integers, but that might be excessively ‘dynamic’.

of course, i’m biased towards lower level design, so it might be that these concerns simply aren’t relevant to scrapscript’s aims.

6

You don’t need native support for sized types to support formats like Protobuf, see how Python handles it in the struct module: you just offload converting from the dynamically sized native types to the intended sized binary representation.

Really not a fan of the JavaScript approach, floats and integers must be separate. On the other hand, I like Lisp/Scheme’s approach to integer/floats: automatic promotion to “BigInt”/“BigFloat” as necessary. It’s a bit more complicated to implement, but makes coding simpler.

1 Like
7

do you have links to the handling? not quite understanding ‘offload converting’

autopromote can be quite simple in certain contexts, if you can detect overflow at runtime - x86 has an ‘overflow’ flag, for instance.

8

Basically you pass in the dynamically sized variable (int/float/whatever) into a function along with some way of representing the desired bitwidth + type + endianness and it outputs the bytes with the corresponding representation.

I’m generally in favor of autopromotion, regardless of complexity.

1 Like
9

hmm, that sounds pretty good as a feature to have for scrapscript anyway, regardless of the choice for integer sizedness

autopromotion and sized types are definitely at odds with each other. sized types with autopromotion would mean that the type of any arithmetic expresson would be, at the very least, a mess.

int8 + int8’s type would be int8|int16. in the case of int16+int8, it’d be int16|int32, and soforth - each addition would potentially be a promotion.

10

If you don’t support autopromotion, you end up with a bunch of ugly type casts like in Go. If you’re going to encode those types of promotions into the type system just have the type system be naive to the bitwidth of the value and be dynamic :slight_smile:

11

yes! that’s my point exactly. you can have one, or the other.

1 Like
12

no, actually. there’s another way!

we could have both, a Number type and Integer types.

Number can be a general, promotable, signed, ‘complex’ numeric type. the representation for Number could be immensely flexible! it could include fractions, it could include floats, etc. and then, where precision, and, importantly, performance, is desired, you can ‘opt in’ to lower, more precise typing - i32, and such. this is the approach that TypedArray in javascript effectively represents. TypedArrays are opt-in performance, but are more annoying to handle than the generic number type. its a tradeoff that you make yourself.

1 Like
13

Sure, but if the goal is parser/compiler/language simplicity, having a mega type and more precise types goes against that, no?

1 Like