Array hashing is complicated

You could print out something however you wanted (and there were functions to print things out in all different ways, like with , instead of . depending on the locale), but what was part of the language itself was the canonic representation of numbers, which was very simple, and could not change.

As far as the speed goes, string operations were very very fast, conversions between strings and numbers were also fast (helped by the fact that numbers were optimized internally as either C ‘int’ integers or a decimal floating point value (64-bit signed integer with a signed byte (decimal) power, which gave almost 19 digits), fancy algorithms like Grisu were not needed). Numeric operations could also be pretty fast, for the most common operations (things like adding up a bunch of floating point numbers, that all had the same scale, such as -2 [think of dealing with money], was just simple 64-bit addition), or multiplying two numbers (just do the multiplication 64x64->128, and only if the result wouldn’t fit back into 64 bits did it need to scale).

Speed really depends on what operations you are performing the most, and for those sorts of applications, it wasn’t considered slow at all.

Suggestion: expand the meaning of ≈ (isapprox) to DWIM (do what it means).
Then each of the following statements should evaluate to true.

1/10 ≈ 1//10
0.1 ≈ 1//10
"1" ≈ 1.0
2 ≈ "2+0im"
" 0 " ≈ "0"   # leading and trailing spaces stripped
NaN ≈ NaN

# the following examples already evaluate to true
2^53+1 ≈ 2.0^53
10e5 ≈ 1000000
1:4 ≈ Any[1,2,3,4]
Float32(pi)+Float32(e)≈Float32(pi) + Float64(Float32(e))