[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fresh syntax and unintentional capture



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