[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: match questions

I think that all of the scheme match proposals I've seen during the
last two weeks, as well as Miranda and other languages favored by the
functional programming community and logic programming languages (any
other oxen to gore?), confuse some things that I work very hard to
keep separate.  Unfortunately, I don't have a word for them, but I can
illustrate my point with one of Wadler's examples.

He wrote:
treenum ::= Leaf num | Branch treenum treenum

sumtree :: treenum -> num
sumtree (Leaf x) = x
sumtree (Branch xt yt) = sumtree xt + sumtree yt

To my mind, the following commonlispish program is superior.  For one
thing, I can change the things that are in a branch without changing
the sumtree program.  Note the absense of positional notation/

(defstruct (leaf weight)
  (weight number))		;;; since this is lisp, type decls are optional

(defstruct (branch left right)
  (right (or leaf branch))
  (left (or leaf branch)))

; This may win the hokiest accessor syntax award but it does
; suggest an obvious extension if multiple values are introduced....
(define (sumtree tree)
  (cond ((leaf? tree) (leaf tree weight))
	((branch? tree) (+ (sumtree (branch tree left))
			   (sumtree (branch tree right))))
	(else <halt and catch fire>)))

(Yes, some people want to push the cond into the function calling
mechanism but since I usually have procedures with multiple arguments,
I don't like to go that far.)

One "feature" of this idea is that it doesn't support "generic"
information, ie things that are common to a number of different
"type", such as printer, since the accessors specify the "type."  This
suggests that T's limited object-oriented style is a big win because
it allows (left tree) to do the right thing even though lots of
"types" have a "left."  On the other hand, perhaps common/inherited
components are rare enough that they should be handled via a separate

I agree that T's destructure, and match-like generalizations of it,
are great, but they're for different problems.  I'd rather use a
different hammer for compound-object problems.