Re: Does ANSI Common Lisp have pattern matching?

On May 8, 11:30 am, Pascal Costanza <p...@xxxxxxxxx> 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. The
disadvantage with if statements is that they are not extensible - and
the same applies to pattern matchers.

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.

That's what dynamic dispatch / OOP is there for to solve this particular
problem. With OOP, whenever you add a subclass, you can also add the
respective new methods that are necessary to glue the subclass with the
rest of the program.

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.

This situation, that you can either extend the data types or the
functionality conveniently is also called the expression problem. There
is no general solution for it that applies without exceptions because
for each function or for each datatype, you have exceptions wrt what
respective specific behaviors should be.

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. All
you need is some way of determining which methods are necessary - but
this is also solved well due to the introspective interface to the
object system which allows you to query the system for existing classes
and their subclasses and existing generic functions and their methods.

As soon as you have dynamic dispatch and dynamic types, the need for
pattern matchers is greatly reduced. 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.

Yes. It is also interesting of your data can be described by patterns
and your operations by applying patterns. Computer Algebra
is such a domain. There are others. You find lots of them
in applications which are using deduction or rule-based systems.
Many uses have been very dynamic in nature. Users can
add, edit or remove rules at runtime. This has been always
very important for knowledge-based systems.

As a tool for programming in certain domains I find it useful.
But then the power of the tool is determined by the domain.

What is missing in CLOS is a generalization of method dispatch.

Is it theoretically missing or practically missing? Is there any
developer of a
software system who says, he I miss this feature?

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). This is not a brand new idea, but there are some
difficult problems involved especially if you want to integrate such
generalized dispatch with a dynamic language. Several people are
currently working on ideas how to integrate this with CLOS, and there
are some good chances that this can be done with only minor
modifications to the overall design and implementation of CLOS.

This already has been explored in the past and I doubt that newer
attempts
will produce something useful. I see there a trend to explore
mechanisms
without having a problem. Later you have a solution but not problem.
I see lots of work on theoretical improvements, but little work based
on
practical needs. There just seems to be little software that is
significant,
where architectural alternatives are explored and the usefulness of
those then can be evaluated.

CLOS breaks done the generic functions into methods. With specific
method
combinations you can get also new ways to specify the purpose of a
particular
method in a generic function.

I'm not sure that exposing too much specifics of the object into the
parameter list is a good idea. An attempt can be seen in presentations
and presentation methods in CLIM. There is lots of complicated
machinery there.

I find this a much more interesting development than the integration of
pattern matcher, which is a non-extensible old hat. You would basically
get pattern matchers for free, but in a much nicer dynamically
extensible setting.

Of course, if you don't care about dynamic extensibility, you can as
well google for "predicate dispatch" to find out about some existing
approaches which already provide such features (including at least one
for CLOS).

Pascal

--
My website:http://p-cos.net
Common Lisp Document Repository:http://cdr.eurolisp.org
Closer to MOP & ContextL:http://common-lisp.net/project/closer/


.

Relevant Pages

  • 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?
    ... standard pattern matcher in the next version of Lisp. ... For SML/Haskell pattern matching, yes. ... if statements / pattern matchers and add new branches to handle the new ... is so useful and cannot be represented using dynamic dispatch and types. ...
    (comp.lang.lisp)
  • Re: merits of Lisp vs Python
    ... long way from the functionality provided by the pattern matchers bundled ... with any of the languages I listed. ... The pattern matchers in ML compilers are thousands of lines of code, ...
    (comp.lang.lisp)
  • Re: merits of Lisp vs Python
    ... long way from the functionality provided by the pattern matchers bundled ... with any of the languages I listed. ... The pattern matchers in ML compilers are thousands of lines of code, ...
    (comp.lang.lisp)