On Mon, Oct 26, 2020 at 1:50 PM Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz> wrote:
>
> 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.

I realize right now we are talking about extensions by other SRFIs/at
the implementation level,
but there are always users who want to match types there are no
patterns for, so I tried to put
some in the spec about that. There are also a number of SRFIs that don't export
their type so matching on them would always involve something like
what's modeled for box
(unless that's what views are for).

I modeled my examples on the forms it takes to add record matching,
and I'm going to clean them
up some, if you have any feedback.

Felix

>
> Regards,
>
> --
> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>
> "When are lurking loop instructions struck from structural inductions?"
> --Conor McBride