FUNCTION-TYPE proposal

[sandra@cs.utah.edu (Sandra J Loosemore)]

I just wanted to clarify the question about item 5 of the FUNCTION-TYPE
proposal that I brought up at the meeting.  The current language in CLtL
*requires* FBOUNDP to return true for a symbol naming a macro or special
form.  The proposal says that *it is permissible* for FBOUNDP to return
true in this situation, which in my mind leaves open the possibility
that it might not return true, and seems to be just the opposite of a
clarification.

Assuming that FBOUNDP must be true of macros and special forms, the 
implication of item 5b is that SYMBOL-FUNCTION must *not* return a
function if the symbol names a macro or special form.  In particular,
the language on p. 144 of CLtL makes it clear that macro functions are
ordinary functions of two arguments and that macro-ness is a property
of the symbol they are attached to, not the function which is used to
produce the expansion of the macro.

Since item 5a says that SYMBOL-FUNCTION must return *something* if its
argument names a macro or special form, and since that something can't
be a function, is there any reason why we couldn't say exactly what
it should return in those situations?  For example, if it returned T,
one could use a bit of code like (AND (FBOUNDP f) (SYMBOL-FUNCTION f))
to test whether the symbol "f" has some interpretation when it appears
as the CAR of a list.  A return value of NIL would also have its uses.
Certainly either one would be more useful than wimping out and saying
it's not well-defined.

-Sandra
-------