On Mon, Oct 26, 2020 at 5:30 PM Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
>
> Am Mo., 26. Okt. 2020 um 22:17 Uhr schrieb Felix Thibault
> <xxxxxx@gmail.com>:
> >
> > On Mon, Oct 26, 2020 at 4:04 PM John Cowan <xxxxxx@ccil.org> wrote:
> > >
> > >
> > >
> > > On Mon, Oct 26, 2020 at 1:50 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:
> > >
> > >> 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.
> > >
> > >
> > > I think the Right Thing here is to resurrect Haskell's idea of views (which are also present in Pure, by the way). Basically a view is a function that transforms an object of some opaque type (defined by a predicate, for Scheme purposes) into an object with a transparent type (most likely a list) that we know how to match on.  Then we just have to teach the matcher about (-> view-proc pattern), which applies view-proc to the object to be matched and matches the result against the pattern.
> > >
> > > See <https://gitlab.haskell.org/ghc/ghc/-/wikis/view-patterns> for details, some of which are unobvious (at least to me).  There are a LOT of other ideas at the bottom of that page, with links, but I think this one hits the sweet spot.  Support belongs in another SRFI, but I believe it is a reasonable extension.  I'd like to reserve patterns beginning with -> and => (these are valid in R6RS, so no problem there) in this SRFI, though.
> > >
> >
> > Is reserving them a matter of adding them to the SRFI as reserved and
> > putting them in the macros as not-implemented-error?
>
> As long as you want your implementation to be implementable just with
> syntax-rules, you cannot special-case all identifiers beginning with
> "->" or "=>".
>
> So, it would just be a matter of the documentation.

Ok, now I would like everyone to engage in a little futurology: these
same operators (or at least ->) were going to be used by
SRFI 197. Would view and view* be better options?