Email list hosting service & mailing list manager

Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (28 Aug 2020 11:49 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (28 Aug 2020 18:06 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (28 Aug 2020 19:22 UTC)
Re: Extensibility (and the lack thereof) John Cowan (29 Aug 2020 00:46 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (29 Aug 2020 08:14 UTC)
Re: Extensibility (and the lack thereof) Wolfgang Corcoran-Mathe (26 Oct 2020 17:50 UTC)
Re: Extensibility (and the lack thereof) John Cowan (26 Oct 2020 20:04 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (26 Oct 2020 20:33 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (26 Oct 2020 21:17 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (26 Oct 2020 21:30 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (26 Oct 2020 22:42 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (26 Oct 2020 22:49 UTC)
Re: Extensibility (and the lack thereof) John Cowan (27 Oct 2020 00:05 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (27 Oct 2020 00:35 UTC)
Re: Extensibility (and the lack thereof) John Cowan (27 Oct 2020 01:59 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (27 Oct 2020 02:18 UTC)
Re: Extensibility (and the lack thereof) Wolfgang Corcoran-Mathe (27 Oct 2020 19:38 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (27 Oct 2020 19:46 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (28 Oct 2020 06:31 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (28 Oct 2020 21:30 UTC)
Re: Extensibility (and the lack thereof) John Cowan (29 Oct 2020 00:17 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (29 Oct 2020 16:42 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (27 Oct 2020 17:20 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (27 Oct 2020 18:42 UTC)

Re: Extensibility (and the lack thereof) Felix Thibault 28 Oct 2020 21:30 UTC

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