[scheme-reports-wg1] Re: [Scheme-reports] [r6rs-discuss] [scheme-reports] Scheme pattern matching & R*RS

[Emmanuel Medernach <emmanuel.medernach@x>]

Hello,

On Sat, Jan 22, 2011 at 4:56 PM, Andre van Tonder <andre@x> wrote:

I used to be all gung ho about pattern matching when I first encountered Scheme, until I started reading some elegant big programs in Scheme and got used to the more Schemely idiom of doing the same kind of thing, which turned out to be as readable and often a better apporoach to abstraction.

I had the same experience. However I would not dismiss the idea completely.
 

What I mean is that pattern matching often does not encourage good abstraction. Which of the following is the better abstracted program (independent of the underlying data type and independent of, for example, adding new fields in data types )?

 (match data
   ((record node l r) (traverse l)
                      (traverse r))
   ((leaf x)          (display x))

or

 (cond ((node? data) (traverse (node-left  data))
                     (traverse (node-right data))
       ((leaf? data) (display (leaf-content data))

ML or Haskell programs are chock full of the former, which looks cool exactly until they want to add an extra field to a data type and all of a sudden realize that they have to change their whole program and all programs that import the same types.

Exactly, one cannot safely rely on patterns: there shapes are syntactically fragile as you demonstrate.  So we have to abstract over shape and confine dependency to small part of code. This is where whether macros or modules may come into play, by proposing an interface over it as in your example.

However this does not rule out pattern matching IMHO. For a related case, we already use it in macros and I believe noone would say here that it is a Bad Thing because of the Scheme/Lisp "code is data" paradigm. So why not having patterns features inside a module ?

Best regards,
--
Emmanuel Medernach