This page is part of the web mail archives of SRFI 93 from before July 7th, 2015. The new archives for SRFI 93 contain all messages, not just those from before July 7th, 2015.
> As I tried to argue in SRFI 72, unless fresh syntax is the default, > it is easy to reproduce in syntax-case all the unintentional capture > problems that hygienic macros were invented to solve in the first > place. No, it's not. In fact, it is impossible to reproduce any of the unintentional capture problems that hygienic macros were invented to solve. The original hygiene condition for macro expansion (Kolbecker, at al, 1986) is stated as follows: Generated identifiers that become binding instances in the completely expanded program must only bind variables that are generated at the same transcription step. The condition has been refined over time, but the basic notion has always been that the bindings and references introduced by a transformer call cannot conflict unintentionally with the bindings and references present in the source or introduced by a different transformer call. The traditional model adopted by SRFI 93, which is implemented by applying a single fresh mark to all identifiers introduced by a given transformer call, is sufficient to ensure that the hygiene condition for macros is met. The fresh mark prevents introduced identifiers from conflicting with identifiers present in the source or introduced by other transformer calls. The unintended captures that can be reproduced, such as the ones that you described in your note and in SRFI 72, are of a different, less common, and less troublesome sort. They are "intra-transformer" captures, which can occur only when the same transformer call introduces two bindings for the same identifier. While I agree it might be nice to protect against this limited sort of unintended capture, and the SRFI 72 model, which applies a fresh mark to the introduced identifiers of each syntax form, can prevent some of this sort of capture, I prefer not to switch to the SRFI 72 model for the following reasons. * The SRFI 72 model would generally complicate without benefit macros that are self-contained, i.e., have only local helpers. I believe that most macros fall into this category. For such macros, it's easy to avoid using the same name for conflicting bindings, and would be awkward to explicitly pull out and commonize the identifiers that should be the same. * The SRFI 72 model would be an incompatible change affecting a large corpus of syntax-case macros written over the dozen or so years since syntax-case was introduced. Furthermore, identifying the places affected by the change would be nontrivial. The SRFI 72 model does have its merits, and, as I mentioned privately back when you were still designing the SRFI 72 system, we've seriously considered the model ourselves. I just don't believe the benefits outweigh the costs. Kent