I had the following conversation on Facebook on 2016-11-20. The material really belongs in the reference section, but that probably won't happen as long as Welly is mocked up inside Python.

Does it have a type uint? If not, why not? If so, fix the documentation

It does not! In this respect it matches the underlying hardware, i.e. the signed/unsigned distinction is a property of the operations not the values. It makes some sense to define the signedness of short ints, e.g. uint8 vs int8, because the operation of sign- or zero-extending them to a 64-bit int is implicit. However, elsewhere you'll be expected to specify the signedness of the operations explicitly, where it matters.

All of this is irrelevant in version 0, which uses arbitrary precision ints because it is mocked up in Python.

Understood. A bit like LLVM (in which int types have size but not signedness). I think I'd need to know the semantics of your operations, when applied to mixed-size types, to figure out whether this is a good idea.

The current plan has downsides but is simple. We will only provide operations on 64-bit ints and conversions to/from 64-bit ints (similar for floats). The small types will be provided via a general mechanism for defining compact representations for other types.

Therefore, the semantics of a mixed operation is to extend both operands to 64 bits and then to perform the operation. So, for example, if x is a uint8, then x >> 3 means zero_extend_8_to_64(x) >> 3. For most operations the implicit expansion to 64 bits is the only place where signedness has any role.

There are a few operations (e.g. <=, %, /, >>) where the signedness of the 64-bit numbers matters. In most of these cases, the signedness of the small types no longer matters after they've been extended to 64 bits, because the expansion creates a load of sign bits.

To make this work, the usual spelling of those operations will give you the signed version of the operation. For the rare cases when you're really using the 64th bit, the unsigned version of the operation will be available under a different name (e.g. le(), umod(), udiv(), >>>).