[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EVAL-WHEN (really symbol-function)



	
    Date: Mon, 7 Apr 86 15:46 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>
    To: hpfclp!diamant@HPLABS.ARPA, common-lisp@SU-AI.ARPA
    Subject: Re: EVAL-WHEN (really symbol-function)
    In-Reply-To: <8604051547.AA06672@GODOT.THINK.COM>
    Message-ID: <860407154604.4.GLS@GUIDO.THINK.COM>
    
	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
      
    ...

    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?
    
    "Having a function definition" merely means "is FBOUNDP"; it doesn't
    mean "has an object of type FUNCTION as the function definition
    attribute".
    
    --Guy
    
1.  How many implementations interpreted CLtL the way Guy intended?
In other words, How many implementations allow, for example,
(setf (symbol-function 'foo) 1.0d0).  VaxLisp does not allow this.

2.  How many implementations interpreted CLtL as implying that only
objects that can be returned from the FUNCTION special form or
objects that are returned by calling SYMBOL-FUNCTION with a symbol
naming a special form or macro as its argument can legally be used as
the value in a SETF of SYMBOL-FUNCTION?  VaxLisp seems to have
interpreted it this way.

I bet that most implemetnations are closer to interpretation 2 than to
1.

3.  Under interp 1. consider the following:

(defun foo () (print "hello"))

(setf (symbol-function 'bar) 'foo)

Which of the following are legal?:

(funcall 'bar) ; A

(funcall #'bar) ; B

(funcall (symbol-function 'bar)) ; C

Case C is the only one I am sure is legal.  The other two depend on
the ambiguous description of function calling (pg. 58) and APPLY (pg.
107).


I guess my point is that I think most implementors followed
interpretation 2 which prevents the kind of confusion where C is legal
but B is not; so we should clarify CLtL in that direction rather than
towards interp 1.

Whatever interp. is finally chosen, APPLY should be clarified so that
we known exactly what can be applied (and if a symbol is applied, what
exactly can be legally the function definition).

	-- Nick