[no subject]

To: Common-Lisp@SU-AI.ARPA

From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

Date: Fri, 02 May 1986 14:54:00 -0000

Sender: FAHLMAN@C.CS.CMU.EDU

In reply to: yuasa at kurims.kurims.kyoto-u.junet
To sum up, there are two possibilities:
[A] (MACROLET ((FOO ...)) (FUNCTION FOO)) causes an error, and
SYMBOL-FUNCTION with non-function symbol also causes an error.
[B] (MACROLET ((FOO ...)) (FUNCTION FOO)) returns some totally random object
which, when invoked as a function, will cause an error. SYMBOL-FUNCTION
with non-function symbol also returns something not a function.
I think that the right move is to go with interpretation A, except that
we would say "is an error" instead of "cuases an error". If existing
implementations do something like B, they would still be allowed, but
people could not count on this behavior in portable code, and it would
be more tasteful to signal an error.
In general, I think we need to allow implementors maximum leeway in
dealing with the function cell and related structures -- the performance
implications can be very substantial. We don't really need to use the
function cell as a place to store random things, and the ability to do
(setf (symbol-function 'foo) (symbol-function 'bar)) for non-functions
is not worth much.
-- Scott