OK, I'll try it out and see how it goes.

On Tue, Jan 26, 2021 at 5:36 AM Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
>
> The matcher code of SRFI 204 keeps track of all ids matched so far. New identifiers are added, for example, here: https://github.com/scheme-requests-for-implementation/srfi-204/blob/master/srfi/204/204.scm#L514. Moreover, they are also (too early, IMHO) bound at this place. To remedy this, record a temporary at the same place and bind the temporary instead:
>
> (let ((%x v)) (sk ... (id+%id ... (x . %x))))
>
> In particular, the id list becomes a list of pairs consisting of the original pattern variable and the renamed one.
>
> Finally, the original variables have to be bound to the temporaries where the body becomes installed:
>
> https://github.com/scheme-requests-for-implementation/srfi-204/blob/master/srfi/204/204.scm#L339
>
> This has to expand into something like (let ((id %id) ...) body).
>
> Of course, these are not the only places where the code has to be adjusted, but this is the general idea.
>
>
> Am Di., 26. Jan. 2021 um 11:15 Uhr schrieb Felix Thibault <xxxxxx@gmail.com>:
>>
>> I'll work on putting the modules in that form while I try to track
>> down some info on how to re-write for late binding (all of my searches
>> so far have turned up results like "Hey! Did you know lisps have late
>> binding?" or "Late binding is important for making methods at
>> run-time." or "Plz read this CommonLisp-Scheme/Scheme-Scheme USENET
>> flamewar")
>>
>> Felix
>>
>> On Tue, Jan 26, 2021 at 4:22 AM Marc Nieper-Wißkirchen
>> <xxxxxx@nieper-wisskirchen.de> wrote:
>> >
>> > In what follows, I am only talking about R7RS, not about earlier Scheme standards, nor generally about implementation-specific stuff.
>> >
>> > In R7RS, we have to distinguish between two forms of `cond-expand`. The first form is an expression (described in 4.2.1. of the R7RS), the second form is a library declaration (described in 5.6.1. of the R7RS). Both forms have the same surface syntax and similar semantics.
>> >
>> > By the R7RS, the syntax of a library definition forces it to begin with `define-library`, so one cannot start a library definition with `cond-expand`, but one can portably use the library declaration form of `cond-expand`, just inside the `define-library` form. On the other hand, R7RS does not specify how library definitions are found by the system when an import is requested. A particular implementation may look for library definitions in implementation-specific `cond-expand` forms in implementation-specific places.
>> >
>> > In an R7RS top-level program, only the expression form of `cond-expand` is allowed. However, it is not available unless imported from `(scheme base)`. So, apart from the fact that an R7RS program has to start with an `import` form anyway, without one, there is no `cond-expand` anyway. As the import declarations in an R7RS top-level program all have to be at the beginning and may not be interspersed with definitions or expressions, one cannot use the `cond-expand` expression to guard imports in top-level programs.
>> >
>> > If you need to do the latter, you have to write a helper library, which is imported by your R7RS top-level program unconditionally, but which itself imports the actual libraries used conditionally through a `cond-expand` library declarations.
>> >
>> > Marc
>> >
>> > Am Di., 26. Jan. 2021 um 08:36 Uhr schrieb Felix Thibault <xxxxxx@gmail.com>:
>> >>
>> >> Looking at R7RS, I see that a library is supposed to start with a
>> >> define-library statement and a program is supposed to start with an
>> >> import statement. Both the main srfi/204.sld library and the
>> >> test/match-test.scm, which cover implementation and testing for Chibi,
>> >> Gauche, Guile, and Larceny, consist of a large cond-expand with a
>> >> block for each implementation (I've seen this style before in, say
>> >> srfi-64/testing.scm).
>> >>
>> >> Even though the standard and practice seemed to be in conflict, it was
>> >> not something I was aware of until I tried to integrate Unsyntax into
>> >> these files. Is this an error or a known issue or what? It seems like
>> >> it would reduce the usefulness of cond-expand if it couldn't be at the
>> >> top, but that's not what the spec says unless I am missing something.
>> >>
>> >> Felix