Re: FUNCTION and MACROLET

[NGALL@G.BBN.COM]

    Date: Wed, 30 Apr 1986  17:44 EDT
    From: Rob MacLachlan <RAM@>
    To:   NGALL@BBNG.ARPA
    Subject: FUNCTION and MACROLET
    In-Reply-To: Msg of 30 Apr 1986  10:28-EDT from NGALL at G.BBN.COM
    Message-ID: <RAM.12203040636.BABYL@>
    
    
	To me, it isn't an obvious clarification that FUNCTION can return
    strange objects.  I always though of function as causing "functional
    evaluation", and would always result in a callable object.
    
	Are people really suggesting that the compiler should arrange to
    compile and dump macrolet functions?  Is this legal?
    
    (defun def-a-macro (name)
      (macrolet ((foo (a b) `(cons ,a ,b)))
	 (setf (symbol-function name) #'foo)))
    
	Of course, if the manual is interpreted as saying that *nothing*
    is guaranteed about what symbol-function returns in the non-function
    case, then the compiler could compile the FUNCTION call so that it
    returned something totally random.
    
	Unless more is guaranteed about what SYMBOL-FUNCTION does in the
    non-function case, this option is useless.  I think it would better to
    say that it is an error to call SYMBOL-FUNCTION on any symbol which
    isn't the name of a function.  Sensibly, it is illegal to do anything
    with a special-form object, and it is much more tasteful to manipulate macro
    definitions using MACRO-FUNCTION, so it seems that the ability to call
    SYMBOL-FUNCTION on non-functions it worthless.   And it we change
    SYMBOL-FUNCTION in this way, then it would be consistent with what
    FUNCTION already does in Spice Lisp.
    
      Rob
    
	      --------------------

I agree that SYMBOL-FUNCTION should be redefined so that "it is an
error" to give it a symbol that is fbound as a macro or special-form
and that FUNCTION be defined analogously.  That will require an
incompatible change to the language, whereas Guy's clarification
(which I was merely interpreting, not supporting) does not.  I am in
favor of such a change, but then I don't have to implement it.

	-- Nick