functionp

[Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>]

    Date: 10 Jul 86 17:05 PDT
    From: Masinter.pa@Xerox.COM

    I've been staring at the spec, and I can't see what would prevent a
    legitimate implementation from defining functionp from universally
    returning T. "functionp is true if its argument is suitable for applying
    to arguments". Now,

If in some implementation (functionp 3) returned T, I would not call
that legitimate.

    (lambda (1 2 &nosuchkey) ...) isn't suitable for applying to arguments
    in the sense that funcall is guaranteed not to complain about it.  

It all depends on what you mean by "suitable for applying to arguments",
which is admittedly a pretty vague phrase.  How about a compiled code
object in which there was a compiler bug that caused the argument-taking
instructions to not be compiled quite right?  What about 
 (defun foo (&optional (x (/ 1 0))) x), which will signal an error during
the argument-passing process if x is not provided?

    I'm wondering if anyone has any portable code where "functionp" has any
    meaningful uses?

The Symbolics software environment uses it in about 35 places.  I just
looked at a few.  In several cases, it's being used to provide error
checking, so that the user will get an error message that says "hey,
that should have been a function, but isn't" as early as possible,
rather than finding out much later when it's harder to debug.  In cases
like the one you present, the user will just find out later, when it's
harder to debug, but at least the functionp will accomplish its purpose
for the vast majority of cases.

In some of the other usages, it's part of what amounts to a user
interface in a software tool, or a facility that does one thing when
given a "function" and another when given a number, or something like
that.  These uses can indeed be somewhat heuristic, in that ambiguous
cases are constructable, but in practice this does not seem to be a big
problem.