> People say that when a piece of Haskell code successfully compiles it is usually correct. LISP can't do this, even though there have been experiments with pluggable type-systems.
Why can't Lisp do this? In the Common Lisp world, there's some pretty aggressive, though still optional, static type checking. There's also Qi, Shen, Typed Racket, et cetera. The question is orthogonal to the question of syntax.
I don't know much about Lisp, but the reason people say this about Haskell isn't just that it has a type system, but a powerful one.
For example, how would you type the cons function? In Haskell, it has type t -> [t] -> [t] (i.e., for all types t, given a value of type t and a value of type list of t it produces a value of type list of t). In Lisp, on the other hand, you can construct a cons cell out of any two objects.
Obviously you can certainly construct a type system in which you can handle Lisp cons cells reasonably; Hindley-Milner type systems aren't the only game in town. But I don't think it'd have the 'if it compiles it probably works' property any more.
The Haskell equivalent of cons would probably be the 2-tuple constructor, (,), which has the type a -> b -> (a,b). You probably wouldn't use it to make data structures like you would in Lisp though.
Why can't Lisp do this? In the Common Lisp world, there's some pretty aggressive, though still optional, static type checking. There's also Qi, Shen, Typed Racket, et cetera. The question is orthogonal to the question of syntax.