On Sat, 22 Jan 2011, David Rush wrote:

> On 22 January 2011 00:09, Andre van Tonder <andre@het.brown.edu> wrote:

>>  It seems to go against the founding moral principles
>> of Scheme.
>
> What? It's a single unifying mechanism for type-dispatch. It allows
> unification of call/return without resorting to CALL-WITH-VALUES.  If
> there's any language idea out in the wild that Scheme *hasn't" got
> already that fits the Clinger criterion more than pattern matching,

At the risk of sounding like a theologist, I suppose we are both referring to
the pronouncement:

   Programming languages should be designed not by piling feature on top of
   feature, but by removing the weaknesses and restrictions that make additional
   features appear necessary.

and, much like theologists, deriving opposite meanings from it.

I consider pattern matching a pretty huge feature that would be justifiable in
the core only if it added orthogonal expressivity, which it does not.

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.

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.

_______________________________________________
r6rs-discuss mailing list
r6rs-discuss@lists.r6rs.org
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss