SETF-FUNCTION-VS-MACRO (Version 2)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 29 Oct 87 15:15 EST
    From: 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.

I guess you're right.  I don't think I'm going to find the time to elaborate
this proposal in the immediate future though.

    And in a few cases, I bet we've not thought out all the consequences enough
    to realize the subtle pitfalls that might follow...

I don't think so, but let's discuss the individual points you listed below.

     * 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.

I can't imagine anyone seriously thinking this, when the proposal says:

  The functions,
  macros, and special forms defined in CLtL and listed in the References
  section above need to be enhanced to accept such lists in addition to
  symbols as function names, so that setf functions can be defined and
  manipulated.

If this doesn't mean that SYMBOL-FUNCTION accepts such a list in addition
to accepting a symbol, then what does it mean?

Aside: in the next edit, the above sentence should read "The functions,
macros, special forms, and declarations ...."

     * 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.

You're right that the proposal needs to say that we are not changing what
CLtL says about (documentation foo 'setf), namely that it applies to defsetf
(and define-setf-method, that's an omission in CLtL).

     * Some people may wonder whether (FLET ((FOO ...)) ...) will implicitly
       make (SETF FOO) lexically funbound. 

I can't imagine why anyone would think that.  Common Lisp doesn't even
have a concept of lexically funbound names (although I think it perhaps ought 
to).

					   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. 

By that reasoning, no language extension of any sort is ever upward compatible,
because a program that purports to understand the entire language won't
know about it.  So I think when we call a change upward-compatible, we must
not be referring to its effect on program-understanding programs.

								       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.

The proposal does say that the INLINE declaration works with (SETF FOO).  I don't
see why the INLINE declaration is more likely to trigger a "red flag" than anything
else, though.  You're right that some programs that assume all function names
are symbols will break if someone feeds them one of these new function names.
In the next version we should add a brief note about that to "conversion cost"
(not "adoption cost", because these programs are not required by CLtL, but are
something added on top of Common Lisp, even if they are written by implementors
and used as part of a Common Lisp compiler.  At least, that's my understanding of
the difference between these two very similar sections of the CL-Cleanup form.)

     * 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 ...).

Good point, that should be added in the next version.

    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.

I will send out a revised proposal with the above small corrections, but I don't
think it's desirable to write a whole paragraph about each of the 16 language
entities named in the References section.  Note that the proposal says nothing
about "attended to in the obvious way".