When extending the matcher, we shouldn't forget that the matcher
naturally applies to *coinductive* values, not to *inductive* values.
Coinductive values are characterized through their deconstructors,
inductive values are characterized through their constructors. And the
matcher basically calls deconstructors and only a finite number of
them in each step.

Directly translating the view concept from Haskell to Scheme destroys
this concept because a view is naturally lazy in Haskell but eager in
Scheme. Whatever general solution we agree on, it also has to be able
to handle streams, for example. The next thing, a possible solution
should be tested against is a lazy, infinite tree.

Am Di., 27. Okt. 2020 um 20:45 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:
>
> Am Di., 27. Okt. 2020 um 20:38 Uhr schrieb Wolfgang Corcoran-Mathe
> <xxxxxx@sigwinch.xyz>:
> >
> > On 2020-10-26 21:58 -0400, John Cowan wrote:
> > > On Mon, Oct 26, 2020 at 8:35 PM Felix Thibault <xxxxxx@gmail.com>
> > > wrote:n
> > >
> > > Wait, is this like (match (view-proc obj) pattern ...)) ?
> > > >
> > >
> > > That was my original idea, but now I think it's better to do it
> > > differently.  I'm going to stick with -> for now, as I think it helps
> > > readability.  Here's an example:
> > >
> > > (define-record-type <point>
> > >   (make-point x y)
> > >   point?
> > >   (x point-x)
> > >   (y point-y))
> > >
> > > (define (point-view pt)
> > >   (if (point? pt)
> > >    (values (point-x pt) (point-y pt))
> > >    (values))
> > >
> > > (define p (make-point 10 20))
> > >
> > > (match p
> > >   ((-> point? point-view 10 y)
> > >     (+ y 1))) => 21
> >
> > This looks very nice!  Maybe this relates to Marc's point about tree
> > patterns, but it seems that we'd want to recursively bring the whole
> > power of the matcher to bear on the patterns appearing after
> > <view-proc>, so that complex structures can be matched without nested
> > matches.  e.g., the pattern grammar would be extended in something like
> > the following manner:
> >
> >     pat :
> >         ⋮
> >         | (-> predicate proc pat1 ... patN)
>
> Yes, something like this. (The predicate may be superfluous if we know
> what we are matching against, but this is secondary.)
>
> The only thing that should be changed in my opinion is the `proc`
> argument, which should become an expand-time object (like a
> record-type descriptor can be).
>
> In some sense, the matching for pat1, ..., patN will be delegated this
> expand-time object (which can, in turn, cause match to be invoked
> recursively).
>
> Marc