Re: Does ANSI Common Lisp have pattern matching?

Pascal Costanza wrote:
Jon Harrop wrote:
The fact is, pattern matching is more common that mapcar. It is
ubiquitous in languages that support it. I think that warrants putting a
standard pattern matcher in the next version of Lisp.

A pattern matcher is essentially a glorified if statement.

No, because "if" statements do not deconstruct. Pattern matching replaces
if/cond/car/cdr/destructuring-bind with a single unified construct that
encourages high-level programming, making for simpler and faster code.

disadvantage with if statements is that they are not extensible - and
the same applies to pattern matchers.

For SML/Haskell pattern matching, yes. In OCaml, you can extend the pattern
matcher using macros. In F#, you can extend the pattern matcher using
active patterns (views).

So if you want to add new subtypes / subclasses to your existing
abstract data types / classes, you have to manually go through all the
if statements / pattern matchers and add new branches to handle the new

Sometimes, yes.

That's what dynamic dispatch / OOP is there for to solve this particular

Except they don't really solve it, they just alter it to make it worse as
you explain here:

However in most OOP approaches, now the problem is turned to the side:
It is now hard to add new functionality, because for each new function
you have to manually go trough all the classes and add the necessary
methods to define the specific behavior for those functions.


As soon as you have dynamic dispatch and dynamic types, the need for
pattern matchers is greatly reduced.

Lisp has those yet it cannot express the symbolic simplifier as elegantly or
efficiently as SML, Haskell, OCaml, F# and many other modern FPLs.

Pattern matchers are indeed more
useful for languages with static type systems where at runtime you
cannot refer to the type of a value anymore.

Scheme and F# are obvious counter examples. F# provides run-time type
information yet pattern matching remains ubiquituous, precisely because it
is so useful and cannot be represented using dynamic dispatch and types.

What is missing in CLOS is a generalization of method dispatch.
Currently, CLOS provides two kinds of specializers: class specializers
and eql specializers which dispatch on the class or on the object
identity of a parameter respectively. It would be nice if we could also
dispatch on more complex predicates, like the contents of a parameter
(for example, if it is a collection), or some other properties (like in
predicate dispatch).

That is probably a definition of pattern matching. The main difference is
that it is dynamic whereas the pattern matchers that I am used to
statically reflect the structure of the data.

I have no experience from CLOS but, from what I have heard, it is extremely
slow. Given that one advantage of pattern matching is performance, perhaps
a CLOS-based implementation is not the way to go?

Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal