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

**DRAFT** issue COMPILED-FUNCTION-REQUIREMENTS, version 2



   Date: Tue, 10 Jan 89 23:24:01 PST
   From: Jon L White <jonl@lucid.com>

   re: MacLisp had a SUBRCALL function, which was
       just like FUNCALL but required its first argument to be a compiled
       function, and it seems like any Lisp for conventional processors could
       make use of such an optimization. 

   And indeed Lucid Common Lisp has a just such function (and also another 
   one corresponding to APPLY).  These have not been exported to end users 
   yet, but are solely used in compiler optimizers etc.  I'm not exactly sure 
   how much optimization they provide, but there should be no real obstacle 
   to making:
	(FUNCALL (THE COMPILED-FUNCTION x) ...)
   turn into
	(FUNCALL-INTERNAL x ...)
   at least in low safety modes.

Not quite.  Lucid's optimization is for the type PROCEDURE, which is
used for both interpreted and compiled functions.  It is equivalent to
the new strict definition of FUNCTION.  An interpreted function is
essentially just a compiled closure that calls EVAL.  It is only
distinguished by a bit in the header so that COMPILED-FUNCTION-P is
not true of it.  The optimized version of FUNCALL eliminates a piece of
code that is equivalent to something like

(UNLESS (PROCEDUREP F)
  (SETQ F (COERCE-TO-PROCEDURE F)))