Should we handle
uint16, etc? Would it be
wise to annotate number literals with a subtype indicator?
Should we handle
Yes. I think for many applications bit size is important. I’m personally a fan of this style:
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?
While generally I agree, pointers and
uint are different types in most languages and different semantics and usage patterns. I typically use
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:
uint are always 64-bits and you keep the bit-specific types (ex.
i32), or you make
uint variable length integers and support a full numeric tower (ie. with “big integer” support) and drop the specific width types entirely.
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?
of course, i’m biased towards lower level design, so it might be that these concerns simply aren’t relevant to scrapscript’s aims.
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.
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.
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.
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.
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
yes! that’s my point exactly. you can have one, or the other.
no, actually. there’s another way!
we could have both, a Number type and Integer types.
Sure, but if the goal is parser/compiler/language simplicity, having a mega type and more precise types goes against that, no?