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) Marc Nieper-Wißkirchen 27 Oct 2020 19:45 UTC

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