This is something I think about a lot. Taking what the mathematicians are doing, and putting it in a programmer-friendly type system (which is a fundamentally different paradigm) is the best idea I have so far – but I haven't really used Haskell, so I don't know if that's what they've already done.
That's a bit different. Haskell has arbitrary precision numeric types, which are commonly found as defaults in scripting languages and usually available as something like "BigInt" libraries or via gmp in C. But this article is talking about behavior when using machine types, not software numerics. Haskell offers types that expose machine integers, and I believe the behavior is truncate if you try to assign something outside of the representable range and wrapping on overflow. I have no idea if that is a standard or just what GHC chooses to do, though.
If you want something closer to what mathematicians are doing, you're probably looking for a computer algebra system, which just reduces symbolic expressions to their simplest form. At some point, you have to plug in actual numbers if you want a numeric output, but by doing it in the simplified representation, you at least avoid all the problems of overflow and truncation that might happen during intermediate computations. Whatever you're doing needs to have an analytic solution, though, and a whole lot of math problems don't. Nearly all of machine learning, for instance, so they'll take a different approach. Often what matters is relative magnitudes, not the exact values, so normalize inputs into a prescribed range you can represent. When dealing with probabilities that can potentially become infinitesimal as in something like language modeling, use log transformations instead, so you get numbers you can represent and you also get the benefit that addition is faster than multiplication.
From the (extremely readable) Haskell Report, §6.4:
> The results of exceptional conditions (such as overflow or underflow) on the fixed-precision numeric types are undefined; an implementation may choose error (⊥, semantically), a truncated value, or a special value such as infinity, indefinite, etc.
So you're right, it's a choice made by GHC. Indeed, by the Report, it would be legal for a Haskell implementation to simply refuse to answer, and never return a value.
