"The ANS allows a compiler to ignore compiler-macros altogether, or whenever it likes. This provision was necessary to get compiler macros into the standard (to avoid imposing new features on implementations unwilling or unable to conform) but this makes the facility portably unusable."
Wouldn't it have been desirable to specify that no implementation is required to honor compiler-macros, but if an implementation does honor compiler-macros sometimes, then it must always support them on a best-effort basis? By "on a best-effort basis" I mean that if there are some corner cases in specific calls for which a compiler-macro might be applicable but the semantics are somehow non-obvious or if there are specific implementation-specific problems with supporting that case, then only then could the implementation not honor the compiler-macro.
Oh, and maybe specify that setting (optimize (space 0)) prevents expansion of compiler-macros...
On Sun, Dec 4, 2011 at 6:02 PM, Steve Haflich shaflich@gmail.com wrote:
Interestingly enough, that also means that there is no ways to use &KEY to specify non-keyword keyword arguments in a compiler-macro lambda-list that doesn't run roughshod across the evaluation model.
I think you mean "non-constant" rather than "keyword". There is nothing special about keyword (which is a constant) and any other constant that eventually evaluates to a symbol.
The real open issuse behind compiler-macros are deeper.
Back in 1989 JonL White (then of Lucid) and I (then and still of Franz) threatened to hold our breath until we turned blue at an X3J13 meeting unless we were permitted to enter a proposal for compiler macros. We worked overnight (I think it was at JonL's house in Palo Alto) to come up with a proposal. It was accepted, subject to a few later emendations, and that is what is in the ANS. Unfortunately, there was not time to give the proposal the traditional trial-by-implementation-and-use, so compiler-macros are not defined completely enough for effective portable use. (But I'm nonetheless glad they are there.)
The ANS is silent on what happens if a compiler-macro signals an error -- not just an error from an unmatchable "keyword" argument. I suggest that the compiler _should_ have been specified to wrap an error handler around compiler-macro expansion, and if any error occurs, the expansion should be treated as ther equivalent of returning &whole.
But even this is not sufficient. The ANS allows a compiler to ignore compiler-macros altogether, or whenever it likes. This provision was necessary to get compiler macros into the standard (to avoid imposing new features on implementations unwilling or unable to conform) but this makes the facility portably unusable. Now, many uses of compiler macros presume nonportable dependencies, such as translating certain references into nonportable lower-level accessors, but IMO it should be possible somehow for portable code to assume that a compiler macro _will_ be expanded in compiled portable code. There ought be some sort of mechanism so the programmer can determine that a compiler macro has signalled error, or that a compiler macro has returned &whole. (Those if us who use compiler-macros currentyl often use disassemble.) I have no proposal how to implement such facilities -- they would live too close to the real estate owned by the programming environment.
pro mailing list pro@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro