[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CLtL error re function special form
Date: Thu, 26 Sep 85 08:01:25 edt
From: Steven Haflich <smh@mit-ems.ARPA>
Surely this must have been noticed before, but on page 87:
function fn [Special Form]
The value of function is always the functional interpretation
of fn; fn is interpreted as if it had appeared in the
functional-position of a function invocation. In particular,
if fn is a symbol, the functional definition associated with
that symbol is returned; see symbol-function. If fn is a
lambda-expression ...
Unlike the function special form, symbol-function does not see lexical
function bindings. The reference to symbol-function here was probably
intended just to convey the distinction between a symbol's `functional'
interpretation and it's `regular' i.e. symbol-value interpretation.
But it's wrong, and potentially misleading.
Fixing the text is awkward because lexical function binding special
forms are not presented until p.113. But CLtL is more of a reference
than a teaching manual. Perhaps the reference to symbol function
should just be deleted.
You're right. The text as it stands is misleading. Thanks for catching it.
A similar but less bothersome slip occurs on p.32 about functional data
types:
A symbol may serve as a function; an attempt to invoke a
symbol as a function causes the contents of the symbol's
function cell to be used. See symbol-function and defun.
I don't regard this one as a slip. In a case such as
(cons a b)
the symbol CONS is not being invoked as a function; rather, it is evaluated
in a functional context to yield a function object, and it is that object
that is invoked. In a situation such as
(apply 'cons args)
then the symbol CONS is invoked as a function (APPLY actually sees the
symbol and must dereference it by fetching the function cell); in the context
(apply #'cons args)
it is not (APPLY never sees the symbol, only the function object).
Some examples of this may be needed.
--Guy