This message contained a lot of inaccuracies
A few more differences between LISP and Haskell:
1) LISP is usually interpreted though most LISP systems allow compilation too.
At the moment, Haskell is a compiled language (though Gofer comes pretty
close to being a Haskell interpreter).
This is a common misperception about Lisp. There are "toy" Lisp
implementations which are interpreted-only, but any serious
implementation comes with a compiler, and any serious application uses
it.
The Yale Haskell system can interpret Haskell code, too.
2) Haskell has data types and pattern matching, LISP does not. To put it
another way, all types in LISP have to be built up from the original
set of types (numbers, characters, pairs) --- and you can't hide the
representation: if you represent triples by nested pairs (_,(_,_)), you
can apply car and cdr (fst and snd in Haskell) to triples.
The claim that Lisp lacks abstract data types is another common
misperception. Things like DEFSTRUCT have been around for a long time in
Lisp (it predates Common Lisp by quite a while!), and good programmers
almost never use long lists to represent data types. Now we also have
CLOS, which provides multiple inheritance.
Most Lisp dialects don't have any sort of destructuring for abstract data
types, but I question whether destructuring is really all that useful
anyway. If you have a type with 20 or 30 components -- which is not all
that unusual, in my experience -- it's much easier to grab the ones you
want by name than by trying to remember the positions of all n
components.
3) Type classes: Haskell has them, LISP doesn't.
Lisp's type system is entirely different than Haskell's, since in Lisp
the type of an object is inherent in the object itself at run time rather
than determined statically by declarations you supply at compile time.
In Lisp, you generally don't need the equivalent of type classes because
you can rely on the dynamic typing mechanism to do the right thing. The
dispatching mechanism for generic functions in CLOS is also dynamic,
rather than relying on static type information.
4) LISP is "reflective". That is, its compiler/interpreter can be invoked
at runtime --- this is very much a part of LISP being interpretive.
This has traditionally been true, but newer dialects are moving towards a
more definite separation between compile-time and run-time semantics.
Neither Scheme nor Dylan includes an EVAL function, for example.
[I'm not sure I understand jcp's comment about Object Oriented Programming:
has LISP changed since I last looked?
Yup.
-Sandra
