On Fri, Dec 2, 2011 at 12:28 AM, Nikodemus Siivola nikodemus@random-state.net wrote:
On 1 December 2011 23:12, Juan Jose Garcia-Ripoll
I _now_ think that the compiler macro processor should simply recognize the failure to parse the form and return the original form, unprocessed
I'm not convinced.
Firstly, the (admittedly non-normative) final example in the DEFINE-COMPILER-MACRO dictionary entry shows that this isn't exactly traditional or something writers of portable code can expect.
Ah, I should have looked at that example.
Still, your argument, though it is a good one, applies somewhat obliquely to Juanjo's question. If our purpose is to make incorrect compiler macros show up early, seems to me, DEFINE-COMPILER-MACRO itself should signal an error (or at least, warn) if the lambda list uses &KEY but not also &REST. This is going to catch a far larger fraction of incorrect complier macros than waiting for the almost vanishingly rare case in which a nonconstant key is used. (Compiler macros are not invoked on APPLY forms; see 3.2.2.1.1.)
To put it another way: by your argument, I think the answer to Juanjo's question doesn't matter very much. While it's true that a compiler macro that could get a keyword parsing error must be wrong, waiting for the parsing error to actually occur is not a very effective way of detecting this class of mistake.
There is another way that a compiler macro's keyword parsing could fail, that seems to me to be much more likely than the use of a nonconstant key: where a function and a compiler macro for it are written, and then some time later, a new keyword is added to the function but the need to do likewise with the compiler macro is overlooked. Although one could argue that getting an error when compiling a form with the new keyword is desirable, as it reminds one to fix the compiler macro, I think the nature of compiler macros is that it's nice when they work but one isn't necessarily counting on them to work, and so ignoring the error is often preferable.
And then, of course, there's the point that a keyword parsing error is not the only kind of error a compiler macro could signal; by the argument I just made, one might well want to ignore all of them.
I guess what I'm muddling towards here is that there should be a compiler parameter *IGNORE-COMPILER-MACRO-ERRORS* that users can set to their preference.
-- Scott