Which makes me start to wonder what big/arbitrary bit-length uints should
One approach is a 'biguint' type that can handle numbers of any (bounded
by implementation) size.
Another approach is to say that you can write uint followed by anything.
eg. uint96 will be the name of a 96-bit uint.
In generated code, those two approaches probably don't look too different
for the most part. But a uint96 knows that it overflows at 2^96, while a
biguint doesn't. So uint96 behaves like a biguint but with typechecking
and operators that can deal with overflows.
Of course, that blows away the parsing model of saying typenames are
keywords - suddenly anything that is ('uint' + a number) is a valid type
name (and correspondingly operators such as add96, addWHATEVER would need
So I'm not sure what I think - if its useful to have the implementation be
detecting overflows then this preserves that in a similar looking syntax.
But it changes the language implementation some.
(a third option is to leave the programmer with uint32 and have them build
their own bigger numbers. but that puts a lot of boilerplate code that
belongs somewhere in the implementation (even if just in something like a
I've been thinking about this and one idea I've had is to have an _
operator, which says what size things are. So, 1_8 would be an 8 bit
one. add_32 would be a 32 bit add (or even, gasp, +_32?).
> So I'm not sure what I think - if its useful to have the implementation be
> detecting overflows then this preserves that in a similar looking syntax.
> But it changes the language implementation some.
> (a third option is to leave the programmer with uint32 and have them build
> their own bigger numbers. but that puts a lot of boilerplate code that
> belongs somewhere in the implementation (even if just in something like a
> standard library))
Yeah, what I've been thinking is that we should have a bignum
implementation in Stupid, but do it in such a way that individual
backends can swap it out for a native one.
Interesting question about arbitrary bit sizes with overflow detection,
required matching of size for operations, etc - once we have bignums it
is, of course, easy to build such a thing on top of it - we'd have to
require some native types, of course, or the bignum implementation would
be recursive :-)
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Skein (for example) has a 7-bit field that is incremented by 1, for