Desk
Desk copied to clipboard
Add N-bit integer types like `i32` and `u8`.
Data
enum Type {
/// N-bit signed integer
Signed { bit: u8 },
//// N-bit unsigned integer
Unsigned { bit: u8 },
...
}
Subtyping
uA<:uBif A <= BiA<:iBif A <= BuA<:iBif A < B (0x1111_ucan be casted to0x01111_i)uN<:'natfor any NiN<:'intfor any N
Coherence
Introducing either or both of the following rules breaks the coherence of the type system
- 🚫
uN<:iNfor any N - 🚫
iN<:uNfor any N
For example: Is <'int> 0b11 -1 or 3?
Syntax
'do <'u3> 0b000;
'do <'u8> 0xff;
$ 1_u8;
$ -2_i32;
*<
& 'u8
& 'i32
>
Naming of u8
- Following the naming of
'intand'nat, it seems thati8orn8would be nice. Likei8is a subset of'int,n8is a subset of'nat. This is not strange. - Following that
u8means "unsigned integer", it seems thats8(means "signed integer") andu8would be nice. - How about
p8(means "positive integer") andi8
But I choose u8 and i8 to minimize surprises for the programmers. Non-programmers may be surprised at u8 but u8 is rare enough for most Desk codes.
How about bits type like b8
It sounds nice, but the following subtyping rules break the coherence of the type system.
bN<:uNfor any NbN<:iNfor any N
So we must throw Rule 2 or both of them away.
Rule 1 is safe and uN <: bN is also safe, so we can say uN = uN. uN is used to represent bits in many languages.
This can be dependent types