On Mon, 26 Jun 2006 xxxxxx@cs.indiana.edu 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