Re: EVAL-WHEN (really symbol-function)

[Guy Steele <gls@THINK-AQUINAS.ARPA>]

    Date: Sat, 5 Apr 86 07:44:35 pst
    From: hpfclp!diamant@hplabs.ARPA
	From: Guy Steele <hplabs!gls@THINK-AQUINAS.ARPA>
	    Date: 4 Apr 1986 09:35-EST
	    From: NGALL@G.BBN.COM
		Date: Thu 3 Apr 86 22:52:12-EST
		From: "Rodney A. Brooks" <BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
		There is no requirement in CLtL that it be legal for a symbol function
		cell to contain a lambda expression. ...
	    This should definitely be pointed out on page 90.  Also, exactly what
	    objects may be the value in a setf of (symbol-function <<symbol>>)
	    should be clarified.
	I would contend that any Lisp object may be the value in a setf of
	(symbol-function <symbol>), and that a subsequent invocation of
	(symbol-function <symbol>) should retrieve exactly that object (or one
	EQL to it).  However, this does not prevent implementations from
	wrapping that object in a closure internally on storing and unwrapping
	it again on fetching.
	--Guy
  
    I have to disagree with you, Guy, for the following reason.  The following
    piece of code is perfectly legal Common Lisp:

    (defun evaluate-fun (func &rest args)
      (if (or (null (symbol-function func))
	      (macro-function func)
	      (special-form-p func))
	  (error "Not a function.")
	  (apply (symbol-function func) args))) ; I know that the symbol-function
						; is redundant here -- that isn't
						; the point

    (evaluate-fun 'cons 'a 'b) ; should return (A . B)

Note that (EVALUATE-FUN 'KDJSHFGDJSAHGFHJSADG) would signal an error
(assuming that KDJSHFGDJSAHGFHJSADG in in fact not FBOUNDP).

      Here is what CLtL says (p. 90):

    "symbol-function returns the current global function definition named by
    symbol.  An error is signalled if the symbol has no function definition;
    see fboundp.  Note that the definition may be an object representing a
    special form or macro.  In the latter case, it is an error to attempt to
    invoke the object as a function."

    Note that the only valid object which may be returned is something of type
    function (if the symbol has a global function definition).  This is obvious
    from the last sentence in the paragraph above.

It may be obvious, but it is also wrong.  I apologize for the misleading
terminology, but the term "function definition" is intended merely as a
label for a certain attribute of a symbol that conventionally has a
function as its value, but it is not meant to imply that that value is
necessarily of type FUNCTION.  Indeed, CLtL does not (I believe) say
that a macro definition object is of type FUNCTION, and such objects are
certainly allowed to be the value of the function definition of a
symbol.  Indeed, the fact that you have a NULL test in EVALUATE-FUN
above indicates that you expect NIL to be a possible result of
SYMBOL-FUNCTION, and NIL is not necessarily of type FUNCTION, is it?

						    Since you claim
    any object can be stored and that the retrieved value must be EQL, then any
    object can be retrieved.  This is totally contradictory to the quoted
    paragraph above.  It very explicitly states in which cases it is an error to
    invoke the object as a function, and the case you are establishing is not
    covered.

"Having a function definition" merely means "is FBOUNDP"; it doesn't
mean "has an object of type FUNCTION as the function definition
attribute".

    As far as allowing a lambda as the function cell, CLtL states that an
    implementation is at liberty to always compile its code.  If the lambda must
    be left in its original state, then the implementation has to compile every
    time a function is called, rather than when one is defined!

Non sequitur.  It doesn't say that the code must be recompiled every
time.  You can compile it once, and the system interpreter can use that
compiled code each time.  It's just that the result of user-visible
calls to SYMBOL-FUNCTION should be the LAMBDA expression.  (We might
want to change that, but that's how I read it now.)

    John Diamant
    Systems Software Operation	UUCP:  {ihnp4!hpfcla,hplabs}!hpfclp!diamant
    Hewlett Packard Co.		ARPA/CSNET: diamant%hpfclp@hplabs
    Fort Collins, CO


--Guy