Most languages have most of the listed features. The most interesting uncommon idea on that list to me is model of time. But only when it allows reversible computing. I don't know how practical that is though. Anyways I've separated out the parts of the list which I think are less common. And listed examples off the top of my head so by no means is the below meant to be exhaustive.
* macros and extensible syntax - the above list, Nemerle, Dylan
* Unification - Prolog, Mercury - logic languages. anyone with type inference. anyone with predicate dispatch, a full example of which I do not know. F# Active patterns and scala extractors are close.
* Error (managing numeric Imprecision) - Best I can understand I can only note that I have seen people treat similar concepts with monads. So haskell and any language which allows easy monads. So scala, f#, haskell, clojure, nemerle
* Math types - Axiom/Aldor. To an extent, dependently typed languages - not practical. yet?
* Polymorphism - Although it sounds more like structural typing. So OCaml, Scala. Also F#, haskell partially.
* Aspects - Metaprogramming makes this relatively easy and clean to implement. so anyone with macros too. Arguably, monads are another way to follow the same philosophy.
* term rewriting - not common, very niche and not mentioned, but pure-lang allows this and for abstract math programming it is a really fun & powerful concept.
* pluggable types - F# has this as type providers. Gosu open types. I have used it in F#. At a start, it is a very awesome way to consume an api.
Less Uncommon:
* pattern matching - most functional languages. to a small extent the java.nexts
* Immutable values - most functional languages
* Parser - parser combinators or any language which implements PEGs e.g. Nemerle
* Design by contract - eiffel and as a library in most languages
I think that the full numeric tower of scheme is what the author had in mind for Math types: big nums, true rationals, strong sense of exactness, etc...
Also, CLOS (Common Lisp) has after, before and around methods for "aspect oriented".
Python is not homoiconic but the ast module allows for wicked stuff.
> Error (managing numeric Imprecision)
Python decimal module does not handle precision error but handles significance, so that(from the doc) "for instance, 1.3 * 1.2 gives 1.56 while 1.30 * 1.20 gives 1.5600". This underrated module also does much more.
Anyway I feel this precision stuff might be a job for numpy/scipy.
The uncommon ones:
* Units - F# and Frink
* homoiconicity - Lisps, Prolog, Io, Factor, Pure?, ...
* macros and extensible syntax - the above list, Nemerle, Dylan
* Unification - Prolog, Mercury - logic languages. anyone with type inference. anyone with predicate dispatch, a full example of which I do not know. F# Active patterns and scala extractors are close.
* Error (managing numeric Imprecision) - Best I can understand I can only note that I have seen people treat similar concepts with monads. So haskell and any language which allows easy monads. So scala, f#, haskell, clojure, nemerle
* Math types - Axiom/Aldor. To an extent, dependently typed languages - not practical. yet?
* Polymorphism - Although it sounds more like structural typing. So OCaml, Scala. Also F#, haskell partially.
* Aspects - Metaprogramming makes this relatively easy and clean to implement. so anyone with macros too. Arguably, monads are another way to follow the same philosophy.
* term rewriting - not common, very niche and not mentioned, but pure-lang allows this and for abstract math programming it is a really fun & powerful concept.
* pluggable types - F# has this as type providers. Gosu open types. I have used it in F#. At a start, it is a very awesome way to consume an api.
Less Uncommon:
* pattern matching - most functional languages. to a small extent the java.nexts
* Immutable values - most functional languages
* Parser - parser combinators or any language which implements PEGs e.g. Nemerle
* Design by contract - eiffel and as a library in most languages
* laziness - the usual functional suspects.