Re: functionp

[Masinter.pa@Xerox.COM]

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

I was using the word "legitimate" to mean "complying with what the book
says", rather than in the sense of following good software design
principles.

I've known Lisp systems which overlayed some range of fixnums with
"binary program space" (Lisp/360 did this, as did Interlisp-10) where
the address of some system functions were indistinguishable from the
address of the integer 3. In such a system, (FUNCTIONP 3) might well be
true, since (symbol-function 'CAR) could return 3. FUNCALLing such a
thing would just start executing that address.

This isn't a great design, and I don't want to defend it, but my point
is that there's nothing in the book to prevent it; there's no
requirement on the FUNCTION type other than that it is true of symbols,
lists that begin with LAMBDA, and of whatever FUNCTION and COMPILE might
return.

I suppose FUNCIONP requires a "clarification", but I'm not sure what the
clarification would say. Here are some random ideas on how to clarify or
modify FUNCTIONP. I don't like any of them very much:

a) "the result of FUNCTIONP is implementation-dependent. Users should
not rely on FUNCTIONP returning anything other than T, although
implementations are encouraged to make the check as specific as
possible. FUNCTIONP is intended for user-interface situations where a
program wants to check as soon as possible whether or not something is a
valid function."

b) change the language to *require* that compiled function objects be a
distinct data type. Define FUNCTIONP to be
(defun functionp (x) (or (symbolp x) (consp x) (compiled-function-p x)))

b') same, but change (consp x) to be (and (consp x) (eq (car x)
'lambda))

c) make a list of types that FUNCTIONP *has* to be disjoint from
(NUMBER, things defined with DEFSTRUCT) but specificly warn that whether
or not other types (VECTOR?) are allowed to intersect with things that
are FUNCTIONP.