[pro] Keyword arguments and compiler macros

[Jean-Philippe Paradis]

"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 at 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 at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
>