Newsgroups: comp.lang.scheme
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: mkatz@garlic.stanford.EDU (Morris Katz)
Subject: Destructuring / pattern-matching (was: Multiple return values)
Message-ID: <9104161557.AA21361@garlic.Stanford.EDU>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
References: <5261@goanna.cs.rmit.oz.au>
Date: 16 Apr 91 15:57:11 GMT
Lines: 39

   Date: 15 Apr 91 10:37:38 GMT
   From: "Richard A. O'Keefe" <ok@goanna.cs.rmit.oz.au>
   Organization: Comp Sci, RMIT, Melbourne, Australia

   In article <12542.9104111347@subnode.aiai.ed.ac.uk>, jeff@aiai.edinburgh.ac.UK (Jeff Dalton) writes:
   > Another problem with patterns in general is that they usually do not
   > respect the abstract structure of objects.  If something is the third
   > element of a list, a pattern will depend on it being the third
   > element; if something is a slot of a struct, the pattern will depend
   > on it being a slot (rather than being accessed some other way).  This
   > is a serious hassle in Prolog, where changing the structure of a term
   > often requires changing patterns all over the program; and since the
   > contents of terms are accessed positionally, it's easy to make a
   > mistake.

   > When people talk of the advantages of pattern-matching in Prolog and
   > functional languages, they seldom mention that it has this disadvantage
   > too.

   (Self-advertisement:  "The Craft of Prolog" _does_ talk about this and
   what to do about it.)

   A possible answer in Lisp-like languages would be to introduce a
   new form

	   (define-pattern (<name> <parameter>...)
		   <simple backquote expression>)

   . . .

For another pattern matching extension to Scheme see Erik Ruf's Stanford
Computer Systems Lab Tech report "LogScheme: Integrating Logic Programming into
Scheme" an earlier draft of which appeared in the proceedings of the 4th ACM
Conference on Functional Programming Languages and Computer Architecture under
the title "Nondeterminism and Unification in LogScheme".
--------------------
Morry Katz
katz@cs.stanford.edu
--------------------