Re: Symbol-function

[hpfclp!diamant@hplabs.ARPA]

     From: hplabs!preece%ccvaxa@gswd-vms (Scott E. Preece)
     
     I don't see any reason to read into the quoted text that those are the
     ONLY cases that may not be invokable.  I read that last sentence as a

You may be correct about the intended meaning of the last sentence.
However, it would have been clearer to explicitly state that it is
an error to invoke any value returned by symbol-function for any symbol
which is not a function (I really mean a function here -- not that it has
a global function definition), and in addition point out that special forms
and macros fall in this category.  In addition, if values are allowed for
symbol-function which aren't functions (or macros or special forms), that
should be stated explicitly.  I don't agree with this rewording, however,
because I don't believe that implementations should be required to allow
anything other than a valid function to be setf'd by the user, and the
requirement on the return value should only be that it is logically equivalent
to what was passed in (that it will do "the right thing").  I already stated
the reasons in my previous message (performance and usability of
symbol-function).

By the way, I just noticed that I dropped a vital part of the sentence
in question when I quoted it.  Look at the quote in my response below.

     cautionary example indicating that not everything residing in that slot
     will be executable.  I agree with Guy that the nature of things put
     into that slot is implementation specific -- portable code should not
     assume anything about it.

I have quoted Guy's comment below, and I don't see how what he said indicates
that portable code can't count on what is in symbol-function.  I think he
is saying that symbol-function is required to act in a portable manner and
that the implementation can have other (non-portable) mechanisms to get to
the non-EQL values it uses internally.  I agree with your statement above;
I just don't think that is what Guy said!
     
     
     From: Guy Steele <hplabs!gls@THINK-AQUINAS.ARPA>
     
     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.
     
     From: Daniel L. Weinreb <hplabs!DLW@SCRC-QUABBIN.ARPA>
     
     Yes, it says that if the object is not a function, it is an error to
     attempt to invoke it.  However, it doesn't say anywhere that if the

It doesn't say that if the object is not a function, it is an error -- it says
that if it is a macro or special form, it is an error.  In particular, it
says that "the definition may be a function or may be an object representing
a special form or macro."  In other words, it may be one of three things.
It may NOT be a random object.  If I say "I may be at home or at work,"
it is correct to assume that I will not be at the beach (assuming I don't
live or work at the beach :-)).

     object is not a function, it is an error to call symbol-function.  So
     there is no contradiction.
     
See above.  I still say there is a contradiction.

     What you say is "obvious" is not obvious at all, because of the fuzzy
     use of the word "valid".
     
The use of the word valid was mine, not from CLtL, so it isn't the root of
the problem.  I think we can all agree that the wording of symbol-function
is unclear, but I am more concerned about changing it so that the requirement
Guy mentioned is NOT made. 

    From: hplabs!Bobrow.pa@Xerox.COM

    The hidden wrapping mentioned earlier (or an implicit wrapping through
    a hash link from the expression) both allow first time compilation rather 
    than every time.  

My comment regarding that was somewhat unclear.  It is true that the
wrapping method does allow an implementation to compile or preprocess in
advance, but it means that the user doesn't really get the symbol-function
when he asks for it.  It means either that 
(apply (symbol-function 'foo)) and (apply 'foo) are different, or that
(apply (copy-list (symbol-function 'foo))) and (apply (symbol-function 'foo))
are different (in the case of a lambda).  There is also a matter of
performance to consider.  Making every function call require an extra hash
lookup (or a test to decide whether to do a hash lookup) is expensive and
doesn't really gain anything for you.  What you are doing is making
the function cell just another value cell.  It isn't.  It is for executable
functions.  Symbol-function ought to return the function cell and the
function cell ought to contain what the implementation really uses to execute
the function.  Also, it should be an error to setf the function cell to
anything which is not of type function.  That would, in fact, eliminate
the problem except for lambdas.

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