> Trinary is philosophically appealing because its ground-floor vocabulary isn’t “yes” and “no”, but rather: “yes”, “no”, and “maybe”. It’s probably a bit much to imagine that this architectural difference could cascade up through the layers of abstraction and tend to produce software with subtler, richer values … yet I do imagine it.
You can just have a struct { case yes; case no; case maybe; } data structure and pepper it throughout your code wherever you think it’d lead to subtler, richer software… sure, it’s not “at the hardware level” (whatever that means given today’s hardware abstractions) but that should let you demonstrate whatever proof of utility you want to demonstrate.
Most usages of a 'bool' are taking up at least a byte, so everyone has 250-odd extra values to play with "at the hardware level" already if they really want.
This - we don't directly bit-address much in computing, so the idea that richness isn't there because of binary is kind of silly. The flexibility is there and you often pay for it either way.
On many 64-bit architectures, you actually waste 63 bits of extra padding for that boolean, for alignment reasons, unless you put some other useful data nearby in your struct (according to the alignment rules).
Luckily, this kind of waste doesn't happen often, but sadly, it does sometimes happen.
You can just have a struct { case yes; case no; case maybe; } data structure and pepper it throughout your code wherever you think it’d lead to subtler, richer software… sure, it’s not “at the hardware level” (whatever that means given today’s hardware abstractions) but that should let you demonstrate whatever proof of utility you want to demonstrate.