Re: [Gcl-devel] Re: [Maxima] Requesting input on some possible low-level changes

[Steve Haflich]

   From: Camm Maguire <address@hidden>
   Date: 09 Sep 2003 15:08:50 -0400
   
   Greetings, and thanks for this!  Problem is, that for the purposes of
   the optimization in question, something can still be usefully done in
   the (apply #'aref ...) et.al. cases (eg. add implicit (the fixnum ..)
   to indices).  I guess this cannot be completely implemented via
   compiler-macros -- I'm wondering if there is a better way?

Well, aref isn't an issue because the ANS prohibits application code
from making compiler macro definitions for CL-package operators
because the implementation might need to do this, and because separate
applications might establish conflicting definitions.  If you have
special issues with particular use of aref, the best thing to do with
any claim of cleanliness and portability is to define your own
function that calls aref, then define a compiler macro for that
function.  The intention would be that the function version would
rarely be called.

Compiler macros have tricky limitations because other than simple
inlining, most of the kinds of things they want to do require being
able to discern a lot about the actual arguments at compile time.
Eliminating the runtime cost of keyword arguments is typical -- an
implementation will typically provide compiler macros for the standard
CL sequence macros to translate common patterns of keyword argument
into calls to specialized versions of the functions, or otherwise, to
inline them.  Consider:

(defun find (item sequence &key from-end (test #'eql) test-not (start 0) end 
key)
  ...)

(define-compiler-macro find
  (&whole whole item sequence &key from-end (test #'eql) test-not (start 0) end 
key)
  ...)

Now, the compiler macro might intend to inline calls with no keyword
arguments other than test, such as

    (find x '(1 2 3 5 8 13 21 34 55 89) :test '<=)

But what if it is called this way?

    (find x '(1 2 3 5 8 13 21 34 55 89) mystery-arg-1 mysetery-arg-2)

This is a putatively legal call to find if the mystery-args are bound
to a keyword arg/value pair accepted by find, but the compiler macro
probably can't discern the actual values at compile time, and so the
compiler macro would want to decline to expand.

But the implementation problem is that the compiler cannot even invoke
the compiler macro if the compiler macro uses normal &key syntax, as
the actual call form at compile time does not match the keyword
argument list.  So the compiler cannot even invoke the compiler macro
without it throwing an error.  Thye compiler instead needs to reason
about whether the actual compile-time calling form is compatible with
the compiler-macro definition, or else wrap an ignore-errors around
compiler macro invocations.  I think the latter is what Allegro does,
but the standard is silent on this detail of semantics.

The problem with apply of a function with a compiler-macro is quite
similar to non-lexically-visible keyword args -- neither the compiler
nor the compiler macro have any general way to know the number of
arguments that will be received at run time.  There should be a
convention the compiler and compiler-macro could use for apply with
the rare compiler macro that doesn't need to know the number of
arguments, etc., but there isn't.  If anyone had a cogent proposal,
the implementor community or standards community could consider it,
but I suspect the general mechanism for this kind of thing would and
should involve a more-ambitious proposal for a walker and first-class
compiler-environment support.