SYMBOL-MACROFLET

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Tue, 13 Sep 88 12:12:45 pdt
    From: Eric Benson <eb@lucid.com>

    This will work:

    (defmacro fsymbolf-fmacrofletf (renamings &body body)
      `(flet ,(mapcar #'(lambda (renaming)
			      `(,(first renaming) (&rest args)
				  (apply #',(second renaming) args)))
			  renamings)
	 (declare (inline ,@(mapcar #'first renamings)))
	 ,@body))

    Of course you won't be happy with the result unless your compiler
    optimizes (APPLY x (LIST a b c)) into (FUNCALL x a b c).

Ours happens to do that optimization, but not everyone's does so it's
bad to rely on that for portable code, which is actually what I was
thinking about. If I was only worried about our own implementations, we
could just have our own private implementation of fsymbolf-fmacrofletf 
and be done with it.

Also, INLINE is not required to be processed by everyone, so there's
another place you might take a runtime speed hit.

Also, some compilers complain when you don't use the function. So you
have to put #'name1 #'name2 ... etc. at toplevel in the FLET body. 
[But then you have to worry that some compilers won't remove that.]

Anyway, we used to do DEFUN-IN-FLAVOR by using FLET, but the practical
fact is that all the smarts needed to make FLET work can be a big drain
on the compiler. If you write zillions of DEFUN-IN-FLAVORs (which some
people do), then -every- method on that flavor (whether it uses the 
function or not) must have this enormous FLET in it just so that the
compiler can optimize it out. It is zillions of times more efficient
at compile time (how's that for an exacting metric?) to use our 
SYMBOL-FMACROLET strategy than to use FLET. It forces the compiler to
do semantic analysis only on demand -- which is what you need to make
a thing like this really useful.

(By the way, I -do- like your choice of name. When I finally talk you
into adopting this, I definitely think that fsymbolf-fmacrofletf
will be the icing on the cake. :-)