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.

The
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
types.

Sometimes, yes.

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

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.

Exactly.

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
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
.



Relevant Pages

  • Re: Does ANSI Common Lisp have pattern matching?
    ... None are as common as any of the other FPLs with pattern matching built in. ... The pattern matchers in Haskell, OCaml, F# and Mathematica ... What if Common Lisp lacked mapcar? ...
    (comp.lang.lisp)
  • Re: Does ANSI Common Lisp have pattern matching?
    ... 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 types. ... 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. ... However, in CLOS the situation is not that pressing: Since in CLOS you define methods outside of classes, you can actually easily do both, add new classes and group the necessary methods with them, or add new generic functions and again group the necessary methods with them. ... As soon as you have dynamic dispatch and dynamic types, the need for pattern matchers is greatly reduced. ...
    (comp.lang.lisp)
  • Re: Does ANSI Common Lisp have pattern matching?
    ... in languages that support it. ... if statements / pattern matchers and add new branches to handle the new ... That's what dynamic dispatch / OOP is there for to solve this particular ... in CLOS the situation is not that pressing: ...
    (comp.lang.lisp)
  • Re: merits of Lisp vs Python
    ... matching library in Lisp. ... I was looking at sourceforge and looked for OCaml downloads. ... Haskell or OCaml. ... That doesn't match the sophistication of the pattern matchers in the ...
    (comp.lang.lisp)
  • Re: merits of Lisp vs Python
    ... | If these things are done well in Lisp then that's great. ... | problem that the userbase will be tiny, e.g. there are probably far more ... Haskell or Mathematica pattern matchers than any given ... 1- lisp code works. ...
    (comp.lang.lisp)