[pro] Keyword arguments and compiler macros

[Scott L. Burson]

On Fri, Dec 2, 2011 at 12:28 AM, Nikodemus Siivola
<nikodemus at 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