On Sat, 2011-01-22 at 10:56 -0500, Andre van Tonder wrote:

> What I mean is that pattern matching often does not encourage good abstraction.

That depends on what abstractions you use for pattern matching. In my
matcher, I would use the following matching based on procedural records
(which is AFAIK the only portable way of writing such a matcher in
R5RS+SRFI)

(cases data
 | (node? node-left =: l node-right =: r) => (traverse l)(traverse r)
 | (leaf? leaf-content =: x) => (display x))

Which looks like, feels like and runs like your second snippet below.

Note that node?, node-left, node-right etc. are not special, only CASES
and =: are;-) If you want you can also use

(cases "123"
 | (string? string->symbol =: s) => s
 | (symbol? (lambda (x) x) =: s) => s)

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

I was not aware the "expresson problem" exists in Scheme (or Lisp or
Clojure or Tcl or any other dynamic language). Assuming your addition of
an extra field is monotonic (no reflection is used), nothing can ever go
wrong, doesn't it?

Kind regards,
Pjotr Kourzanov

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports