The biggest problem is that the author seems to be completely ignorant (willfully or otherwise) of the issues involved at the hardware level.
They go so far as to point out that high-level languages shouldn't have these limitations (sure, agreed), but then is baffled that something like C/C++ does (and should).
C maps more-or-less directly onto assembly, which in turn maps more-or-less directly onto command bit vectors for an ALU. There is no magic decision in the industry to use twos-complement, wrapping arithmetic, or fixed-size integers (which map onto machine words).
This person needs to spend some quality time with low-level architectural stuff and gain a better understanding of why things are the way they are.
(not that the points are bad, necessarily, for a DSL or something--but stay out of our systems languages!)
EDIT: Okay, author is clearly somewhat knowledgeable about the field, but still... these are interesting ideas that don't really make sense for low-level stuff. It's not a matter of allocating enough memory (for bignums or whatever)--it's how the mapping occurs to the actual hardware instructions and datatypes.
You and others seem to be missing that he is talking about the default 'int' type. If you want a specific overflow behavior, he implies that would be under a different name. I agree -- 'int' doesn't need to be the type that maps most efficiently to the hardware, even in a "systems language". It can and should be a fairly efficient type that has reasonable semantics.
Modifying a 2s complement ALU so that if the overflow bit is set, then every bit of the result is set to 1 would be trivial. It's just another n OR gates, and those are pretty cheap (OK, you'd probably want an AND against a control bit, too).
The author doesn't ignore that this would require a change at the hardware level - he says "Processor architectures will have to add a family of integer math instructions that properly propagate NaN values..." - and he is right that the change would not be a costly one.
> The biggest problem is that the author seems to be completely ignorant (willfully or otherwise) of the issues involved at the hardware level.
There's not any issues at the hardware level. Integer arithmetic is simplistic mostly because languages that run on current CPU's have simplistic integer semantics. It's not because more complicated semantics would be impossible to implement at the hardware level.
Take a look at some of the complex integer instructions that SSE supports with single-cycle latency.
They go so far as to point out that high-level languages shouldn't have these limitations (sure, agreed), but then is baffled that something like C/C++ does (and should).
C maps more-or-less directly onto assembly, which in turn maps more-or-less directly onto command bit vectors for an ALU. There is no magic decision in the industry to use twos-complement, wrapping arithmetic, or fixed-size integers (which map onto machine words).
This person needs to spend some quality time with low-level architectural stuff and gain a better understanding of why things are the way they are.
(not that the points are bad, necessarily, for a DSL or something--but stay out of our systems languages!)
EDIT: Okay, author is clearly somewhat knowledgeable about the field, but still... these are interesting ideas that don't really make sense for low-level stuff. It's not a matter of allocating enough memory (for bignums or whatever)--it's how the mapping occurs to the actual hardware instructions and datatypes.