Funcallable instances in SBCL are implemented as a subtype of
function, and as such must be directly funcallable using the same
calling sequence as ordinary functions and closure objects, which means
reading the first word of the object after the header, and then jumping
to it (with an offset on non-x86 platforms). It must be possible to set
the function of a funcallable instance, as CLOS (one user of funcallable
instances) computes and sets the discriminating function for generic
functions with sb-mop:set-funcallable-instance-function, and also
allows the user to do the same.
Additionally, although this functionality is not exported to the normal
user, they must support an arbitrary number of slots definable with
!defstruct-with-alternate-metaclass. If generic functions were
the only users of funcallable instances, then this might be less
critical, but (as of SBCL 0.9.17) other users of funcallable instances
are: the ctor make-instance optimization; the
method-function funcallable instance which does the bookkeeping
for fast method function optimization; and interpreted functions in the
full evaluator.