2025, we can all just use integers and carry one less variable type in our sack.
Next we replace integers with floats and we’re done. 3 birds, 1 stone.
2025, we can all just use integers and carry one less variable type in our sack.
Next we replace integers with floats and we’re done. 3 birds, 1 stone.
true = 1
false = 0
perhaps = 0.5- NARS2000 dialect of APL, Ball / Interval arithmetic: https://wiki.nars2000.org/index.php/Ball_Arithmetic
There's a robot controller that I work with that has a large number of calibration tables, of float32 values. This is where I store the json! :D
I highly doubt that. Let's call a boolean that is represented as one bit "true boolean type" Since no instruction set (that i'm aware of) has boolean operators, a "true boolean" would require every operation on it to evaluate to multiple bit-wise operations, which take up registers and cycles. Flags in registers are "true boolean", but they're usually operated on explicitly like int with bit-wise operators.
There is also the issue of bit alignment, atomic access, and stack and heap allocations being byte based; further restricting how a language that had "true booleans" would be able to actually be able to work with them.
I know that there are some languages that allow boolean arrays to be packed tightly as "true boolean", but that is a rare exception. Even char and byte types has this issue sometimes, but are more commonly "properly packed".
> we can all just use integers
So it's all integers already. The most common implementation of boolean around is probably #define true 1
But we really should use enums more instead of boolean. "fail, success, bad_param, error_404" is equally efficient to return as a bool.
> Next we replace integers with floats.
No. (well python and JavaScript kinda does already, but no) https://en.wikipedia.org/wiki/Pentium_FDIV_bug