[pro] Keyword arguments and compiler macros

Steve Haflich shaflich at gmail.com
Sun Dec 4 23:02:48 UTC 2011


>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20111204/f09096ec/attachment.html>


More information about the pro mailing list