SETF-FUNCTION-VS-MACRO (Version 2)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 29 Oct 87 13:43 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    ...
    I don't understand what you find insufficiently explicit about this now.
    Do you mean that we should say
      (defun (setf foo) ...) works like (defun foo ...)
      (flet (((setf foo) ... works like (flet ((foo ...
      (declare (inline (setf foo))) works like (declare (inline foo))
      (symbol-function '(setf foo)) works like (symbol-function 'foo)
      and so on for all the rest of them?
    That seems pretty pointless to me.  You must mean something more profound,
    but I don't see what.
    ...

I don't think I meant anything drastically profound in any given case, but I
do think it's more important to do this enumeration than you're suggesting.
Many ``obvious'' things follow from the statements in your proposal, but some
of them may be surprising to some people, depending on how far their forward
chaining theorem prover runs when they read the descriptions you've provided.
And in a few cases, I bet we've not thought out all the consequences enough
to realize the subtle pitfalls that might follow...

 * Some people will distrust their ability to extrapolate and be likely
   to say to themselves: ``Surely they couldn't have meant that I should
   write (SYMBOL-FUNCTION '(SETF FOO)).'' By stating this explicitly,
   we'll confirm that this extrapolation is correct.

 * Some people may expect that
    (DEFUN (SETF FOO) (VAL) ...)
   sets up (DOCUMENTATION '(SETF FOO) 'FUNCTION) while others may expect
   that it sets up (DOCUMENTATION 'FOO 'SETF). Some may expect that 
   (DOCUMENTATION 'FOO 'SETF) is oboleted, while others may assume that
   you now have to know how the SETF thing was defined in order to get
   its documentation. Others may expect (DOCUMENTATION 'FOO 'SETF) to 
   apply only to SETF macros and (DOCUMENTATION '(SETF FOO) 'FUNCTION)
   to apply to SETF functions, independently of how they're defined.

 * Some people may wonder whether (FLET ((FOO ...)) ...) will implicitly
   make (SETF FOO) lexically funbound. By writing things out in English,
   we have a place where we can be explicit remarks about this. They may
   be redundant with logical consequences of things you've already written,
   but I think some such redundancy is appropriate in a proposal of this
   kind.

 * By the way, some people, myself included, have functions which map
   down existing linguistic constructs such as declarations and do things
   like GET on them because they presuppose that the things they're
   operating on will be symbols. Since GET works only on symbols, such
   code will be broken by this so-called upward compatible change. A more
   subtle consequence is something which takes a function name and does
   MEMBER into a list of function names. That won't blow out but unless
   :TEST #'EQUAL is added, it will no longer reliably find the function name.
   By mentioning things like (PROCLAIM '(INLINE (SETF FOO))) you may trigger
   a red flag in some people's brains that alerts them to a potential
   impact of this change which you had not anticipated.

 * You need to specify things like how the implicit block in (SETF FOO)
   generalizes. Does (RETURN-FROM (SETF FOO) ...) work, or does it just
   create a (BLOCK FOO ...).

I could probably think of more of these. I think that by making a little paragraph
that claims to explain the extrapolation technique for each of these functions,
we will make it more likely that someone will notice other little nagging oversights
that need to be explicitly addressed. As long as you just say "and these will
be attended to in the obvious way" there is nothing to criticize/correct and yet
grave potential for loose ends to be left dangling.