[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] [r6rs-discuss] [scheme-reports] Scheme pattern matching & R*RS
On Sat, 22 Jan 2011, David Rush wrote:
On 22 January 2011 00:09, Andre van Tonder <andre@x> wrote:
It seems to go against the founding moral principles
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
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
((record node l r) (traverse l)
((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
Scheme-reports mailing list