What numeric types should your wide-spectrum, all-domain FoC language support? Douglas Crockford <http://dec64.com/> claims that decimal floating point (his DEC64 data type) should be "the only number type in the next generation of application programming languages". Binary floating point is unsafe for financial calculations, so DEC64 is a good choice for spreadsheets or any language that does financial calculations. But Crockford also says DEC64 is "well suited to most scientific applications", and that's less clear. I do agree that for an end-user programming language focused on a specific domain, the simplicity of a single numeric type is valuable. And DEC64 is a good choice if the domain involves finance. For my language Curv, a DSL for 3D graphics, the best choice is IEEE binary floating point as the single numeric type. For scientific computation, the popular choice is a batteries-included language with all the features needed by experts. Experts also need speed, because some scientific computations take a long time to run. That means you need vectorized IEEE binary floating point. Nobody will ever port BLAS and LAPACK to DEC64. Ditto for Machine Learning and 3D Graphics (which run on a GPU): you need vectorized binary floating point, because that's what the hardware supports. For a functional language like Idris, where you use dependent types to prove programs correct, you need a natural number type, Nat, which implements the Peano axioms directly. In the Idris standard library,

data Nat = Z | S Nat

. You need this so that you can perform inductive proofs over the natural numbers. You need other numeric types as well (Nat doesn't include negative numbers or fractions). In systems languages like C, C++ and Rust, you need the full set of numeric types supported by the hardware, including int8, int16, int32 and int64, so that you can write high performance code that optimizes memory consumption and memory access patterns and uses the L1 cache efficiently. A true wide spectrum language would presumably need to support all of these different kinds of numeric computation, and in each case, do as good a job as more specialized languages designed by domain experts. And that would make the language much more complicated than a domain specific language. For any given task, a DSL is probably a better choice.

DSLs are better than wide spectrum languages because they are simpler. There is less to learn. The syntax can be specialized for the task. The semantics can be restricted to only what is needed for the task, which leads to cleaner, simpler semantics.

I currently distinguish between integers and reals in my system, but I don't like it. I strongly agree with the spirit of your "single numeric type is simpler" sentiment. I have aims of moving to a more Haskell-y system in my platform. (Hindley-milner is already there, so a good chunk groundwork is laid)

Although if you want One Format To Rule Them All, quad-precision float has an appeal— the mantissa is 112 bits (which means integers 112 bits or smaller are exact), and my favorite fact about quad floats is that if 1.0 is 1 AU, then (1ulp) : (the radius of a hydrogen atom) :: (radius of hydrogen atom) : (radius of Earth). "128 bits ought to be enough for anybody."