5 ms·
NewtonScript had 31-bit integers, rather than 32-bit, for the exact same reason. It was a complete mess. Famously the Newton had its own Y2K bug (the 2010 bug
by SeanLuke 3y ago
NewtonScript had 31-bit integers, rather than 32-bit, for the exact same reason. It was a complete mess. Famously the Newton had its own Y2K bug (the 2010 bug) because dates could only be expressed with 31 bits.
If a language needs to rely on pointer tags for GC, avoid that language.
- Someone 3y agoI don’t see how one library for one language having some undesirable feature implies “If a language needs to rely on pointer tags for GC, avoid that language.”, especially not since using tagged pointers does not necessarily imply limiting the range of integers. An implementation can choose to implement ‘small’ objects as tagged pointers, and use a pointer to an ‘integer’ object for objects it cannot ’hide’ inside a pointer.
- rollcat 3y agoEveryone has already realised that 32-ish bit values are too little to represent time with either sufficient range or precision, I wouldn't blame the issue on 31-bit integers specifically (that one bit hardly buys you much time), but on the short-sightedness of whoever chose to use them for that purpose. A 63-bit integer would give you 145 years of range at nanosecond resolution; if you chose millisecond precision instead, you could accurately timestamp the death of the last mammoth.
- SeanLuke 3y agoThis was just one example of where 31-bit ints bit you in NewtonScript. But there were many more, especially when dealing with interoperability with the OS, which was in C++.
- lispm 3y agoLisp?