Re: Incompatibility with pattern matching
Michael Sperber 20 Sep 2005 10:36 UTC
Andre van Tonder <xxxxxx@now.het.brown.edu> writes:
> It seems that the constructor paradigm chosen in the draft does not easily
> accommodate future extensions for pattern matching. The problem is that a
> constructor can be many to one. E.g., in
>
> (define-type foo (x y)
> (fields a immutable (+ x y)))
>
> we cannot automatically generate a pattern that can be used (like in MzScheme):
>
> (match (make-foo 1 2)
> ((make-foo x y) .....))
>
> Indeed, since the record types of this SRFI are not freely generated,
> automatic destructuring is not a sensible operation.
This is true as far as pattern matching by position is concerned. I
personally think this is a good thing, as pattern matching by position
scales very poorly.
I don't think your argument extends to pattern matching by name, and I
can imagine a variety of abstractions on top of the SRFI draft that
would accomodate it.
<
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla