Xref: utzoo comp.lang.functional:153 comp.lang.prolog:2759
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!bruce!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.functional,comp.lang.prolog
Subject: Re: Pattern matching considered harmful
Message-ID: <3136@goanna.cs.rmit.oz.au>
Date: 3 Jun 90 06:54:45 GMT
References: <2584@skye.ed.ac.uk> <3077@goanna.cs.rmit.oz.au> <2790@syma.sussex.ac.uk>
Followup-To: comp.lang.prolog
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 80

In article <2790@syma.sussex.ac.uk>, aarons@syma.sussex.ac.uk (Aaron Sloman) writes:
> 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:
> > I am very much in agreement with [not over-using pattern matching].
> > 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.

There isn't any difference.  Hence the argument passing conventions
of MESA, Ada, and VAX/VMS Pascal, amongst others.  (Also SML's
record patterns, not to mention AMBER.)

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

The trouble is that "segment variable" patterns apply only to lists.
There is no common notation for saying "somewhere within this tree".

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

In Prolog, I'd do it using two DEC-10 Prolog library predicates:
	member(AB_list, X),		% now in library(basics)
	pairfrom(AB_list, A, B, _)	% now in library(sets)
or by using a grammar rule body:
	member(AB_list, X),
	phrase(( lit(_), [a], lit(_), [b], lit(_) ), AB_list)
_This_ kind of pattern matching just doesn't come up often enough to
be worth having a special notation.  One of the first projects I did
was Prolog was to figure out how to translate Interlisp's pattern-
matching notation to Prolog; in the process of doing it I realised
that it was just as simple to write the appropriate Prolog code in
the first place.

In the SML and LML programs that I have seen, there seems to be a fairly
serious move away from lists.  On the whole I think this is a Good Thing.

> 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.)

Well, here's how you would write it in Prolog.  What do _you_ think?

	append(_, [X,Found|_], List)

or, if you really want to write out a pattern,

	phrase(( lit(_), [X,Found], lit(_) ), List)

Interlisp, of course, could do it much the same way that Pop-11 does.

-- 
"A 7th class of programs, correct in every way, is believed to exist by a
few computer scientists.  However, no example could be found to include here."