On Tue, Oct 27, 2020 at 1:20 PM Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
>
> Am Di., 27. Okt. 2020 um 01:05 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
> >
> > "Beginning with ->" was a mistake.  I conflated two statements:  (a) I want to reserve -> and => (b) R6RS does not have a problem with either of these identifiers, even though identifiers are not allowed to begin with "-".  To which I add (c) that I don't care what we reserve, as long we reserve two things.
> >
> > On Mon, Oct 26, 2020 at 5:30 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
> >
> >> How is this supposed to be efficient?
> >
> >
> > It's primarily intended to be complete.  Dynamically typed lists are a universal data structure; that's one of McCarthy's original theorems.  If you know how to match a list and you have views, you can match anything at all.
>
> That's for sure an important observation. In fact, it says that a
> matcher basically only has to understand simple s-expressions. A proof
> of this fact is the Scheme language itself with the matcher being
> syntax-rules (or, rather, syntax-case, the left-hand side of the
> syntax-rules pattern-template language).
>
> What we are free to choose, though, is whether the lists only exist
> transiently (at expand-time) or whether the runtime matching processes
> actual lists.
>
> >> This would construct an object just to have it deconstructed.
> >
> >
> > A very good point.  So let's make it (view view-proc pattern ...), where view-proc takes the object to match and returns multiple values that are matched against the patterns.
>
> That looks better! But what about opaque tree structures? With your
> original proposal, in which the view returns a list, one can easily
> generalized it to returning s-expressions in which the tree structures
> has been replayed. Of course, the constructing/deconstructing issue
> would become even more of a problem (because more structure is
> replicated), but a more efficient alternative shouldn't be less
> expressive.
>
> To find a good solution, one should go back to the root cause, I
> think, which is (a) the limitation of "match" to finitely many types
> of forms and (b) the desire that, syntactically, a use of "match"
> looks like matching against s-expressions, for which "match"s syntax
> is tailored.
>
> I think the obvious solution is to parameterize the "match", i.e. to
> teach it on a case-by-case basis how to match certain opaque
> structures with its s-expression syntax. As "match" is a macro,
> syntactic parameterization (not to be confused with syntax parameters)
> will just do it and we don't have to worry about any runtime overhead.
>

Is this also a change that can be set up by referring to it in this
SRFI and then implementing it in a future one,
or is just a change in implementation,
or does it involve the spec, too?

> (The runtime overhead I have been worrying about would be the typical
> runtime overhead of using the wrong tool for the job so that the job
> is being adapted at runtime so that it fits the tool. Sometimes, this
> is inevitable, but this should mostly be true when fitting legacy
> code.)