Am Do., 20. Aug. 2020 um 22:23 Uhr schrieb Felix Thibault
<xxxxxx@gmail.com>:

> The library already doesn't include ... in the literals list, match-one and match-extract-vars pass their arguments off to match-check-ellipsis when the time comes to look for them, then if one is found arguments get passed to whichever match-gen-ellipsis is appropriate. So it's only the ..1/..=/..* forms that get picked up as literals by match-two and match-extract-vars (then passed off to their respective match-gen-ellipsis).

I haven't looked at the source code. But then you can hopefully play
the same trick with "_" with not too many conversions into
continuation-passing style.

>
> On Thu, Aug 20, 2020 at 2:58 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> Am Do., 20. Aug. 2020 um 19:02 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>>
>> > _ banned explicitly in R6RS
>>
>> Not banned, but not easily matchable with an R7RS-conformant implementation.
>>
>> > ... OK because a peculiar identifier
>>
>> This has the same problem as _ for R6RS, I think.
>>
>> PS Contrary to what I said before, _ (and ... as well) are actually
>> matchable with syntax-rules even if they don't appear as part of the
>> list of literal identifiers. First, check with the usual tricks that
>> some input element is an identifier and then expand into a macro that
>> uses that element as part of the pattern and template and which
>> behaves differently (but well-defined) whether the inserted element is
>> _ or not. The same holds true for ....