> 1) LISP is usually interpreted though most LISP systems allow
> compilation too.
This is not really a language issue, more a question of implementation
tradition. Most Lisp implementations have interpreters, though some
always compile.
However, a fair number of programmers always, or almost always, run
their code compiled. For instance, I'm working on a largish program
now, and I never run it interpreted.
> At the moment, Haskell is a compiled language
I'm not convinced that there's such a thing as an interpreted or
compiled language, at least when it comes to reasonably general
programming languages. For instance, Basic is often said to be
an interpreted language, but Dartmouth's implementatins have always
been compilers.
>
> 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.
It's not true that all types in Lisp (that's "Lisp", not "LISP" --
see Steele's book 2nd ed, and other recent language definitions)
have to be built up from numbers, characters, and pairs. (Also,
perhaps you meant sybols rather than, or in addition to, characters?
There's no way in modern Lisps to build up symbols from those other
types.)
In particular, if I define a new class, instances of that class
cannot be operated on as numbers, characters, or pairs (unless,
of course, the class is a subclass of one of those other types).
Now pattern-matching is often positional. This is not abstract
and has many of the same problems as using things like caddr.
Anyway, it's easy to define pattern-matching for Lisp if you
want it. If pattern-matching really did confer large advantages,
I am convinced that it would now be a fairly standard part of
Lisp (as, say, object-oriented extensions now are). N.B. this
is not to say pattern-matching confers no advantages or that it
is not a perfectly good way to do many things.
BTW, in general I think it works better to talk about particular
kinds of Lisp (e.g. Common Lisp, EuLisp, Scheme) rather than about
an unqualified "Lisp". Of course, it's possible to make meaningful
claims about Lisp in general, but inferences drawn from only one
or two kinds of Lisp will often be wrong. (Lisps vary more than
one might expect given that they're all often considered somehow
the same thing.)
-- jeff
-- jeff
