On 25 Oct 2025, at 17:05, Sergei Egorov <xxxxxx@acm.org> wrote: > In this light, I believe this aspect of the discussion is best approached from an engineering pragmatics perspective. Binding pattern variables "as you go" (and as proposed for the `match*` form) is the most natural and direct way to implement it; most implementations I am familiar with do it this way. It is quite easy, if one uses a more powerful macro system than syntax-rules, to implement the Right Thing where pattern variables are only bound in the body and not in other subpatterns. (Given this is what you actually wrote in the spec, and in your proposed resolution you make it ‘an error’ to break the restriction, I have to assume you agree that ideally this is what a maximally correct implementation would do.) Before it grew a decision tree generator and an AST which implicitly takes care of ensuring that no variable names are bound in the wrong places, extensible-match used the implementation strategy you mention. But it used an initial ‘alpha conversion’ phase to replace every variable in the input with a generated identifier, which was then let-bound back to the right name only once the whole pattern was known to have matched. <https://codeberg.org/dpk/extensible-match/src/commit/7f2e8ba888f27bd452eb51876f4a329308b89dc2/extensible-match/expand.sls#L155> <https://codeberg.org/dpk/extensible-match/src/commit/7f2e8ba888f27bd452eb51876f4a329308b89dc2/extensible-match/core-pattern.sls#L102> (The current implementation still uses essentially the same strategy to control scope, but its implementation is a bit more diffuse than this.) If you were willing to add a dependency on SRFI 148, you could do this without too much difficulty. In ‘pure’ syntax-rules this is also possible (SRFI 148 is itself implemented in syntax-rules), but I assume the prospect of all those doubly-recursive expansions expressed in CPS style to do the renaming is putting you off. Two references to the Church–Turing Fathers, relevant to this decision motivated by a decision to restrict the design by reference to what can be done in a grotesquely underpowered implementation system: ‘Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy’ — Alan Perlis, Epigrams on Programming 54 The whole notion of sacrificing the correctness of an interface in order to make the implementation ‘simpler’, especially because one denies oneself the tools to easily create a correct implementation, is the essence of Worse is Better; I like to think we still aim higher than this in Scheme: <https://www.dreamsongs.com/WIB.html#:~:text=2.1%20The%20Rise%20of%20Worse%20is%20Better> Daphne
