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

Re: EVAL-WHEN (really symbol-function)

    Date: Wed, 9 Apr 86 21:08:05 GMT
    From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
    To: NGALL@bbng.arpa, gls@aquinas.think.com
    Subject: Re: EVAL-WHEN (really symbol-function)
    Message-ID: <12977.8604092108@aiva.ed.ac.uk>
       Date: 8 Apr 1986 17:34-EST
       From: NGALL@arpa.bbng
       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.
    I tried (setf (symbol-function 'foo) 'bar) in the two CLs within easy
    reach.  Both signal errors, and not particularly nice ones either.  (I'd
    expect something like "illegal value ~S for SYMBOL-FUNCTION", but I get
    things like "segmentation-violation".)
       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.
    Case C should be legal because it should be the same as (funcall 'foo).
    Case B should also be legal because #'bar == (function bar) should be
    equivalent to (symbol-function 'bar) in a context where bar refers to a
    global function (i.e., when there's no lexically enclosing flet or
    labels that binds bar), as it does in this case.

One of (:->) the definitions of FUNCTION on pg. 87 states that "FN is
interpreted as if it had appeared in the functional position of a
function invocation".  As most of us would agree (but CLtL does not
pin down), the function call (bar) is erroneous (again, CLtL does not
define what should happen when the function definition is illegal or
even unbound).  By this definition of FUNCTION then, (function bar) is
erroneous.  Up until now, I think most people thought that (bar) and
(funcall (function bar)) were semantically equivalent (i.e., both are
illegal).  By your definition of FUNCTION (as being eqiv. to
SYMBOL-FUNCTION in the case of a global function name), the former is
still illegal but the latter is perfectly legal. Yecch! I'll stick
with my reading of FUNCTION.
    Case A should be illegal, but CLtL does not explicitly exclude it.
       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.
    I don't think there is a case where C should be legal and B not.
As I showed above, I think there is.
       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).
    I agree that the definition of APPLY is deficient.  For example, it
    seems to list explicitly all the things that might be functions and yet
    it never mentions closures.  Compare this list to that on page 32.
    In general, my favorite pages for answering questions concerning what
    things are legal as functions are pages 32 (section 2.13) and 59
    (section 5.2).  Page 59 is, for example, the place where the distinction
    between the use of lambda-expressions and symbols as *names* for
    functions and their use as function objects is most clearly made.

Thank you for pointing out pg 32.  It states that "The result of
evaluating a FUNCTION special form will always be a function."  If we
accept this statement.  Then under interp. 2:

(setf (symbol-function 'zap) 1.0)

What does this return?:

(function zap) =>

A) 1.0 ;  According to your definition of FUNCTION.

B) <<a function that when called will barf>>.

C) Undefined by CL (implementations are encouraged to signal an error).
I hope that I have made my point that interp. 2 is unintuitive (since
most implementations didn't do it that way) and leads to confusion.

	-- Nick