Email list hosting service & mailing list manager

Incompatibility with pattern matching Andre van Tonder (19 Sep 2005 14:02 UTC)
Re: Incompatibility with pattern matching Michael Sperber (20 Sep 2005 10:36 UTC)
Re: Incompatibility with pattern matching Andre van Tonder (20 Sep 2005 15:46 UTC)
Re: Incompatibility with pattern matching Michael Sperber (20 Sep 2005 16:04 UTC)
Re: Incompatibility with pattern matching Marcin 'Qrczak' Kowalczyk (20 Sep 2005 12:02 UTC)

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