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 _______________________________________________ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
