* Racket doesn't meaningfully have a good syntax for literal maps or sets
* Racket doesn't have math-oriented types, AFAIK, even in Typed Racket
* Racket doesn't have units.
* Racket doesn't have aspects (you can obviously add them--see Swindle--
but Swindle is very rare these days, and not the preferred way to write
Racket
* Racket is not interface-based (ditto)
* Racket *supports* immutable values, but mutable (via define) seems more common.
The MLs or Clojure seem a lot closer here.
* Racket is arguably not polymorphic. I'm aware you can do weird stuff by
playing with a bunch of hidden parameters on structures, but the description
sounds a lot closer to OCaml functors to me. (And look no further than
how Racket has for/list, for/hash, for/gvector, etc., for a harsh example of the
limits of that polymorphism.)
Comprehensions such as for/list and for/hash are polymorphic, in that they operate on arbitrary sequences, of whatever type. for/list constructs lists; for/hash constructs hashes. Clojure, a language that takes uniformity of interface much further than Racket, has similar operations.
You're completely right on the math. I had math-oriented types wrong; I assumed that the author wanted the ability to say, "This type is restricted to values defined by this set," which he didn't. Even if he did, I see that Typed Racket actually does support such types, which is awesome. So I'm completely wrong.
Whether e.g. #hash((key . value) (key . value)) counts as a literal hash syntax is interesting. If you want to argue it does, then I'll argue that C does, too, since I can trivially #define my way there through C99 struct assignments and a function that constructs a hash off an array of those structs, or that C# does because I can use an initializer (e.g., "new Dictionary<string, string> {{"Foo", "Bar"}, {"Baz", "Quux"}}"). Literal hashtables and vectors, to me, means something that's visually apart from base syntax forms, specifically so that it stands out to the coder. By this standard, Python, Ruby, Smalltalk, and Clojure would qualify, while Racket, Io, and C# would not. Whether that matters to you depends on what you want.
I don't think that's right about hash tables. In particular, the distinction I would make is that literal hash tables are part of the syntax of the language in Racket, like in Clojure, Python, etc, and not in C# or C. What this means in Racket is that (read (open-input-string "#hash()")) produces a hash table -- that's parsing, not running the hash table constructor.
Racket doesn't have math-oriented types, AFAIK, even in Typed Racket
As far as I know, it uses "machine-oriented" data representation when it can (sufficiently small integers, inexact numbers) and promotes to arbitrary-precision representation when it has to (larger integers, non-integer rationals). I don't know how much more OP expects out of "math-oriented" numbers than what's explicitly listed (no overflow, rational division).
There exists a matrix library, but it might be lacking some desired operations. I'm not sure what OP means by having "equation" as a type.
