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.
On Mon, 26 Jun 2006 dyb@xxxxxxxxxxxxxx wrote:
Andre wrote: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.
Granted. I will not dispute the original intent of the Founders. Yet many inter-transformer potential captures can be directly mapped to intra-transformer potential captures by simply converting a transformer to a helper procedure, which is not an uncommon occurrence. The examples I listed
were the result of such a mapping.
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.
I do not agree that it is necessarily less troublesome. I have run into very troublesome bugs caused by this issue, where macros silently gave the wrong answer some time after they had already been tested, because of an obscure identifier conflict.
I submit that the conventional model makes it impossible to reliably write helper procedures shared by different macros, since such procedures would have to know all surrounding bound identifiers potentially introduced by all
possible present and future callers. For example, the helper (define (helper) (syntax (list 1 2 3)))will fail if any future caller inserts the result in code where LIST has been rebound.
The only solution I see, in the current model, is for the helper procedure to list all identifiers it introduces as part of its public interface. The
author of any caller then has to manually ensure that it does not rebind any of these identifiers. Needless to say, this is fragile and error-prone. My only conclusion is that the conventional model is not intended for certain styles of procedural macro-writing. This is a legitimate restriction, but since it is not enforced, users should be made aware of it.
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.
Fair enough. I just wanted to make sure the issue was recorded in the discussion list.
Regards Andre