I would have loked to see a quotation from the parts of the standard that are referred to here: "Although few implementations support its full generality in file compilation, a strict reading of the Common Lisp specification seems to imply that writing the following should be acceptable".
The perspective that the author is missing (and also not well articulated in the references he might have been chasing) is that the problem of hygiene exists even if you take away macros.
Macros only hide an unwanted clash; they are not what makes the unwanted clash possible. Clashes can happen out in the open, and still go unnoticed, causing a problem.
A hygienic macro system only fixes the problem for macros.
The real fix is to diagnose instances of shadowing. It's that simple. If you diagnose shadowing, scope-related name clashes, such as those macros can run into, have nowhere to hide.
Diagnosing shadowing won't catch every hygiene bug in a macro; only when that bug reproduces. If a macro generates code which binds some famous library function, then every instance of the macro will be diagnosed. If the macro binds some unused identifier, then instances of the macro will only be diagnosed when it is planted into code that defines the identifier. Still, diagnosed is diagnosed; the programmer is alerted to the problem, and even if they are not able to fix the macro, they may be able to work around it by renaming something in their code.
9 comments
[ 3.2 ms ] story [ 31.8 ms ] threadI would have loked to see a quotation from the parts of the standard that are referred to here: "Although few implementations support its full generality in file compilation, a strict reading of the Common Lisp specification seems to imply that writing the following should be acceptable".
Macros only hide an unwanted clash; they are not what makes the unwanted clash possible. Clashes can happen out in the open, and still go unnoticed, causing a problem.
A hygienic macro system only fixes the problem for macros.
The real fix is to diagnose instances of shadowing. It's that simple. If you diagnose shadowing, scope-related name clashes, such as those macros can run into, have nowhere to hide.
Diagnosing shadowing won't catch every hygiene bug in a macro; only when that bug reproduces. If a macro generates code which binds some famous library function, then every instance of the macro will be diagnosed. If the macro binds some unused identifier, then instances of the macro will only be diagnosed when it is planted into code that defines the identifier. Still, diagnosed is diagnosed; the programmer is alerted to the problem, and even if they are not able to fix the macro, they may be able to work around it by renaming something in their code.