On Wed, Oct 28, 2020 at 2:31 AM Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
>
> 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

I have a file matching example in the extension section already (in
what I'm currently
working on- I added (match (proc data) (pat ...))
as an alternate way to deal with data that is opaque to the matcher)
so I changed it from reading in a whole file then matching on that to matching
on each read- which seems like it would be easier to convert to a stream reader
in a future SRFI, and a note at the end of the section that a future
SRFI will specify
a method similar to this one using pattern operators -> and => to set
up views on
data.

Felix

> 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