gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Steve Haflich
Subject: Re: [Gcl-devel] Re: [Maxima] Requesting input on some possible low-level changes
Date: Mon, 08 Sep 2003 15:09:17 -0700

   From: Camm Maguire <address@hidden>
   
   In any case, our define-compiler-macro appears to be lacking in at
   least one respect, namely it doesn't skip over 'funcall as required by
   the spec.  I.e. (funcall #'foo ...) is not expanded.  I have a fix to
   this which seems to be working.  What I'd like to know, however, is if
   'apply, 'map, and any other functions taking a function descriptor as
   an argument is also supposed to be expanded.

No, the ANS only specifies that funcall be handled.  Compiler macros
should not be invoked for apply or mapping forms.

A plausible reason for this is that for a compiler macro to be useful,
in many situations it needs to know the number of arguments the
operator will receive at run time, and for keyword args, it often
wants to see the actual keyword arguments at compile time.  (Compiler
macros typically will punt if this information is not available to
them.)  There is no reasonable way to destructure an apply or map form
against the `macro' lambda list of a compiler macro.  For funcall it
is quite practical.

Note that the compiler macro receives the funcall form as its &whole
(so that it can return it if it decides to decline to expand) but that
the compiler is responsible for unravelling the funcall form so the
compiler-macro's macro argument list is properly bound.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]