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.

(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.)