[r6rs-discuss] [scheme-reports] Scheme pattern matching & R*RS
peter.kourzanov at gmail.com
Sat Jan 22 19:00:49 EST 2011
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
| (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
| (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))
> (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?
More information about the r6rs-discuss