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