0.pre7.71:
[sbcl.git] / src / code / target-defstruct.lisp
index 9af080e..eb08e47 100644 (file)
 (defun %set-funcallable-instance-info (fin i new-value)
   (%set-funcallable-instance-info fin i new-value))
 
-(defun funcallable-instance-function (fin)
+(defun funcallable-instance-fun (fin)
   (%funcallable-instance-lexenv fin))
 
 ;;; The heart of the magic of funcallable instances ("FINs"). The
 ;;; both the code pointer and the lexenv, since that code pointer (for
 ;;; an instance-lambda) is expecting that lexenv to be accessed. This
 ;;; effectively pre-flattens what would otherwise be a chain of
-;;; indirections. Lest this sound like an excessively obscure case,
-;;; note that it happens when PCL dispatch functions are
-;;; byte-compiled.
+;;; indirections. (That used to happen when PCL dispatch functions
+;;; were byte-compiled; now that the byte compiler is gone, I can't
+;;; think of another example offhand. -- WHN 2001-10-06)
 ;;;
 ;;; The only loss is that if someone accesses the
-;;; FUNCALLABLE-INSTANCE-FUNCTION, then won't get a FIN back. This
-;;; probably doesn't matter, since PCL only sets the FIN function. And
-;;; the only reason that interpreted functions are FINs instead of
-;;; bare closures is for debuggability.
-(defun (setf funcallable-instance-function) (new-value fin)
-  (setf (%funcallable-instance-function fin)
-       (%closure-function new-value))
+;;; FUNCALLABLE-INSTANCE-FUN, then won't get a FIN back. This probably
+;;; doesn't matter, since PCL only sets the FIN function. And the only
+;;; reason that interpreted functions are FINs instead of bare
+;;; closures is for debuggability.
+(defun (setf funcallable-instance-fun) (new-value fin)
+  (setf (%funcallable-instance-fun fin)
+       (%closure-fun new-value))
   (setf (%funcallable-instance-lexenv fin)
        (if (funcallable-instance-p new-value)
            (%funcallable-instance-lexenv new-value)