Dunno, ML-based languages have a pretty different feel to Lisp. They're compiled languages, have type inference, heavily rely on pattern matching, type declarations. An example from OCaml's front page:
type tree = Leaf of int | Node of tree * tree
let rec exists_leaf test tree =
match tree with
| Leaf v -> test v
| Node (left, right) ->
exists_leaf test left
|| exists_leaf test right
let has_even_leaf tree =
exists_leaf (fun n -> n mod 2 = 0) tree
Most LISP implementations also provide compilers. The difference is that ML variants are statically typed, while LISPs are generally dynamically typed.
Yes... you can have type inference as well (if you wish[1][2]). I guess the philosophy is to use it if you need it but otherwise you might prefer to stick to the dynamic part.
But they are essentially garbage are they not? Adding java-style static typing is not helpful at all. The benefits of static typing are very much tied to the power of the type system in question.
Typed Racket definitely doesn't add a "Java-style static typing" system at all. Its type system is quite specifically designed to accommodate the kinds of programming idioms you find in Racket programs (via occurrence typing, function intersection types, and so on), and comes with local type inference.
I don't use racket obviously, but looking through the docs on typed racket it certainly looks like it adds java-style static typing. Having crappy partial type inference doesn't make the type system powerful or expressive, C# has that too and it certainly falls into the java-style type system camp.
> but looking through the docs on typed racket it certainly looks like it adds java-style static typing
It's unclear what you mean by "Java-style static typing" then, because the Java type system and Typed Racket's type system are completely different.
One actually has local type inference (which is not "crappy" type inference necessarily; HM-style type inference is notoriously brittle), the other doesn't. One has nominal class types, the other has no class types (yet). One has intersection types, occurrence typing, "true" union types, and so on, while the other has none of those. One has bounded polymorphism, the other has System F-like polymorphism. One of them has variable-arity polymorphism, while the other doesn't. The list goes on.
In fact, aside from being explicitly typed, there are few similarities.
Which is totally orthogonal to the power and expressiveness of the type system. I specifically gave an example that C# also has crappy limited type inference too, and is still java-style static typing.
>HM-style type inference is notoriously brittle
Yeah, obviously no languages could possibly exist that use it with no problems.
>One has nominal class types, the other has no class types (yet)
What does being OO have to do with anything? I am talking about the expressiveness of the type system. The amount of things you can express in the type system.
>One has intersection types, occurrence typing, "true" union types
So racket has a partial implementation of ADTs? And that's it? Ok, you win, racket has java + 0.1 level of static typing, hooray! The point is, using static typing in racket gets you virtually nothing, because it is such a primitive type system. Go use ML or haskell and then compare it to typed racket.
>One of the main benefits of static typing is to detect errors at compile time
Obviously. But a static type system that lacks power and expressiveness is very constraining and can detect very few classes of errors. Hence the example of java, a very inexpressive static type system.
>BTW, static typing goes way before Java :)
Again, obviously. Why are you saying random obvious things to me?
Your comment is even dumber than I would expect from you. That is a very impressive feat. Non-sequiturs don't become relevant because you say "DURRRR".
type tree = Leaf of int | Node of tree * tree
let rec exists_leaf test tree = match tree with | Leaf v -> test v | Node (left, right) -> exists_leaf test left || exists_leaf test right
let has_even_leaf tree = exists_leaf (fun n -> n mod 2 = 0) tree