I think I have found a solution that will enable a macro to handle an
infinite set of auxiliary syntax (like syntax representing positional
parameters "_0", "_1", "_2" in possible extensions of SRFI 26, SRFI
197, etc.):

What I can add to SRFI 206 before it is finalized is to mandate that
(srfi 206) exports an identifier "auxiliary-syntax-name", which will
be exported in meta level 1 for implementations with explicit phasing.
This identifier can then be used as a property key in the sense of
SRFI 213. Every auxiliary keyword binding will then have an implicit
property that associates to "auxiliary-syntax-name" the name of the
auxiliary syntax as a symbol. It will be an error to modify this
property through SRFI 213's define-property.

This will allow for full inspection.

What do you think?

Marc

Am Mo., 24. Aug. 2020 um 17:31 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:
>
> On the mailing list of SRFI 197, for the chain macro defined by SRFI
> 197, Arne asked about arbitrary positional parameters "_0", "_1",
> ..."_9" as auxiliary syntax.
>
> The limit of 10 positional parameters is, of course, somewhat
> arbitrary but any hygienic syntax-rules implementation has to have
> some limitations because only a finite number of predefined
> identifiers can be matched literally.
>
> For a more powerful macro system, however, an unlimited number of
> parameters "_0", ... "_99", ..., "_666", ... is possible for a macro
> in conjunction with SRFI 206:
>
> The user of the macro imports the needed parameters from the magic
> library (srfi 206 *). The macro itself, which wants to match these,
> may have to create these on the fly for comparison. For this,
> "define-auxiliary-syntax" is used.
>
> Note that this not a full solution yet. The problem is that the macro
> in question has to be able to detect whether an argument is an
> argument of the "_?". Otherwise, it is not clear how many placeholders
> have to be created on the fly. Another primitive that allows
> introspection of auxiliary syntax seems to be necessary. I welcome any
> suggestion that doesn't stretch the usual expansion system.