SETF-FUNCTION-VS-MACRO (Version 2)

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

In general, I support the idea of the SETF-FUNCTIONS proposal for this issue.
I'd like to see some presentation issues get cleared up, though, before it
goes to X3J13...

 * Currently the proposal section 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."
   I'm sympathetic to this in principle but I don't think this is adequately
   explicit for us to vote in. For example,

    . I think we have to explicitly mention notation issues such as the
      syntax for INLINE and FTYPE declarations in the proposal section.

    . I think we have to mention how DEFUN and FLET are extended, not just
      provide examples that seem to imply something.

    . We need to talk about what FMAKUNBOUND, FBOUNDP, DISASSEMBLE,
      DOCUMENTATION, etc. individually/explicitly. It's ok for Moon to have
      proposed the issue to CL-Cleanup at this level of sketchiness so he
      didn't have to work too hard to get it on the table, but I think we
      should flesh this out before it goes to the full committee. Experience
      with places in CLtL that ask the reader to extrapolate should have 
      taught us by now that this is pretty dangerous to depend upon.

 * Moon's reply to Gregor's remark about package::|SETF -name-| is important.
   In general, such an approach would require the space of symbols in the
   given package to be extended if you wanted to make something SETF-able
   which had not previously been. Using the list notation does not have this
   bad misfeature. This should definitely be mentioned in the discussion.

 * The lettered items in the discussion (paths not taken) should be worded
   in some sort of parallel style. As it is now, some seem to be questions and
   some statements.