On 2020-08-29 10:13 +0200, Marc Nieper-Wißkirchen wrote:
> Am Sa., 29. Aug. 2020 um 02:46 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
> >
> > Well, it will go in the ballot, where you may certainly vote against it.
>
> I'd rather hope that we can find a technically convincing solution
> while this SRFI is still in draft mode.

I'd second this emphatically.  Few ideas suffer more from a restricted
view of Scheme types than pattern-matching.  Any number of extensions
seem plausible (what if we want our matcher to match ilists, boxes,
mappings, or some other type yet to be invented?), but, as noted
above, such extensions may break compatibility.  The only alternative
is the rather miserable makeshift of writing implementation-based
patterns (e.g. matching records or whatever "nuts and bolts" a type is
represented by).

I understand Felix's rationale that these limitations are inherent in
the matcher presented here, though.  Given how popular the WCS matcher
is, I agree that this SRFI is a very good thing.  But I do think that
we need something better in the long run.

Regards,

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"When are lurking loop instructions struck from structural inductions?"
--Conor McBride