Xref: utzoo comp.lang.functional:148 comp.lang.prolog:2754
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!uunet!mcsun!ukc!icdoc!syma!aarons
From: aarons@syma.sussex.ac.uk (Aaron Sloman)
Newsgroups: comp.lang.functional,comp.lang.prolog
Subject: Re: Pattern matching considered harmful
Message-ID: <2790@syma.sussex.ac.uk>
Date: 2 Jun 90 15:57:33 GMT
References: <2584@skye.ed.ac.uk> <3077@goanna.cs.rmit.oz.au>
Organization: School of Cognitive & Computing Sciences, Sussex Univ. UK
Lines: 82

Because I only sample net news at random, I have not read the
preceding discussion, but thought I'd comment on the following, at
the risk of having missed the point:

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:

> Date: 26 May 90 09:00:22 GMT
> Organization: Comp Sci, RMIT, Melbourne, Australia
>
> In article <2584@skye.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
    .....
> > ....However, programmers all too often use pattern
> > matching throughout their programs and then, when they change the
> > number or order of fields in a structure, have to go around and change
> > all the patterns.  Moreover, to read a pattern one often has to count
> > commas, which is error-prone to say the least.
>
> I am very much in agreement with this.
> As an example, suppose you have some data type which represents
> a finite function (a dictionary).
    ....

I don't see any difference between this problem and the problem
arising in any programming language where you define procedures or
functions with arguments of certain types and then have to invoke
them by giving the right number of arguments in the right order.

If you change your procedure definition, e.g. because you discover
that an extra argument adds extra generality, then you have to find
all locations in the program where it is invoked and edit them.

The only difference in the prolog case is that if you fail to make
the required changes, instead of a run-time or compile-time error
you will often simply get obscure behaviour.

As far as the advantages of pattern matching are concerned, I have
found that the use of a pattern matcher with "segment" variables
often makes it much easier to express accurately and clearly what
you want to do with a complex structure than other commonly used
mechanisms.

E.g. to check whether something (x) is a list one of whose elements
is a list containing "a" preceded by "b" with an arbitrary number of
elements in between, in Pop-11 you'd write

    if x matches [ == [ == a == b == ] == ] then ....

where "==" matches an arbitrary number of items. In most languages
you'd have to write at least three nested loops to do this and would
probably not get it right first time.

Similarly, you could define a procedure to search for x in a list,
and return the next item, thus:

    define successor(x, list) -> result;
        vars found;
        if list matches [== ^x ?found ==] then
            found -> result
        else
            false -> result
        endif
    enddefine;

(where "^" means use the value of, and "?" means "set the value of")
which I think is clearer than anything you could write in lisp or
Prolog. (Prolog matches "segments" only at the end of the list.)

(Actually, the Pop-11 version could be made more compact in
various ways.)

I'd far rather teach people to USE list processing using a pattern
matcher than have students struggle with hd and tl. Later, if
necessary, they can learn the lower level mechanisms.

Of course, the price of a pattern matcher, may be efficiency, but
often that's not so important as clarity, maintainability, and
reduced development time.

Aaron Sloman,
School of Cognitive and Computing Sciences,
Univ of Sussex, Brighton, BN1 9QH, England
    EMAIL   aarons@cogs.sussex.ac.uk