If Scheme's numbers were like Scheme

Interestingly, this is the case in OCaml (albeit with a shorter syntax), and it is very handy.

OCaml has two separate operators for integer addition (+) and float addition (+.), and it is illegal to write something like "1.5 + 1.5", as you either have to write "1.5 +. 1.5" or convert them to integers. This is used for the strong type checking of OCaml.

While this seems annoying at first, I found this to be very practical, especially in numerical algorithms. In other languages like C/C++/Java you always struggle with implicit conversions between int and double. When do these really happen, given all those implicit rules? If you care about correctness, you'll find yourself casting stuff to double or int/long, like this:

  (double)(SOME_EXPRESSION) / (double)(ANOTHER_EXPRESSION)

  (SOME_EXPRESSION) /. (ANOTHER_EXPRESSION)

You'll then have to add explicit conversions wherever needed, but this is really the lesser evil – especially since it gives you full control over when this actually happens.

I think many of the design choices the author is griping about (which numbers mercifully avoid) is an illustration of this tendency, which itself is a result of the two boats Scheme had a leg in for years: both a minimalistic language with elegant semantics, useful for pedagogy and optimal for hobby implementations ("50-page purists") and a viable, modern, competitive language for nontrivial applications.

Despite all this, you'll take my Scheme and Racket away from my cold, dead hands.

[1]: http://www.scheme-reports.org/2009/position-statement.html

Edit: ... as well as methods for reading and displaying numbers.

"What would Scheme be like if numbers followed the same style as the rest of the language?

It would be necessary to import a library before using any numbers."

Every language has primitive types. I don't see any Schemers complaining about that fact. Sure, maybe you find it annoying that you have to (import srfi-69) to use hashmaps, and that the accessor functions have verbose signatures: (hashmap-ref ht key), etc. I think the author is forgetting that Scheme gives you the power to easily define a new syntax for yourself that does not affect the regularity of the rest of the language.

"Numbers would have no printed representation."

I'm reading this as a complaint about there not being a default printing representation for types like records. I don't see how this is a valid complaint. The point of using a record is presumably to distinguish your data type from any old vector. Almost all implementations will allow you to define your own printed representation if you want.

"There would be no polymorphism. Most operations would include a type in their name."

R5RS does not have type signatures for functions. If you want to write a ref procedure that works on vectors and lists, you can. In fact:

(define (ref x n) (cond ((list? x) (list-ref x n)) ((vector? x) (vector-ref x n)) (else #f)))

"But the lack of polymorphism would make it even more obvious that in practice exactness was simply one of the type distinctions: that between floats and everything else."

For lack of a better word, this seems like a strawman. I think it was a practical idea to have the language distinguish between exact and inexact numbers. Interestingly, Chicken Scheme implements the numeric tower in an library (the numbers egg) instead of in the standard distribution.

"Names would be descriptive, like inexact-rational-square-root and exact-integer-greatest-common-divisor."

I much prefer descriptive names that I can easily shorten using macros or functions to overloading the binary shift operator to write to streams.

"Converting the lists into strings would be up to you."

I guess this is a complaint about how small the standard library is. This is part of a larger debate within the Scheme community. See R7RS-large vs. R7RS-small. Many people think the latter is more to the nature of Scheme.

"This would really be about whether numeric operations should always return fresh numbers, and whether the compiler would be allowed to copy them, but no one would mention these merely implementational issues."

Relying on undefined behavior is an implementational issue. To quote R5Rs, "Eq?'s behavior on numbers and characters is implementation-dependent, but it will always return either true or false, and will return true only when eqv? would also return true." If you want defined behavior, why are you comparing things that can't already be compared with =, string=?, & co? Comparing a vector to a number doesn't make much sense.

"There would still be no bitwise operations on integers. Schemers who understood the purpose would advise using an implementation that supports bitvectors instead of abusing numbers. Those who did not would say they're easy to implement."

This point I am sympathetic to. But it seems to me a bit like complaining new language X does not support feature Y that language Z does. If feature Y is so important, why not decide whether or not it's worth your time to implement it and if not go with whatever language would be the most convenient to you? It's the same as many other decisions in life.

Numerical Tower is Scheme's invention. It is one of Scheme's distinct features and a major innovation of that time.

R5RS, which is considered the classic Scheme (some would even say R4RS) has only Strings and Vectors as an ADTs with such convention of naming procedures. It amounts for just one page of the standard. And, of course, not these two types is the essence of Scheme.

Also Scheme precedes CL, which incorporates Numerical Tower from Scheme.