Re: Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)

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

    Date: 1 Feb 89 11:48 PST
    From: masinter.pa@Xerox.COM

    ??? GETHASH returns two values, yet your examples has it returning 3. 

Sorry. That was a Genera extension creeping in. Normally Cloe protects
me from such things, but I guess I missed that one.

    I'm baffled by this issue, however. "SETF may be used with GETHASH to make
    new entries in a hash table. ... The default argument may be specified to
    GETHASH in this context; it is ignored by SETF, but may be useful in such
    macros as INCF that are related to SETF." 

I have to say that this case-by-case treatment upsets my sensibilities.

For example, consider SUBSEQ. Its treatment of optionals is not spelled out
in its description, but is apparently spelled out in the description of
DEFSETF.

However, as you observe, it is apparently the status quo, and it's late
in the cycle, so...

    This seems perfectly clear to me. I don't think that this is a SETF policy
    at all. I think you should withdraw this. 

Would anyone object if I instructed Kathy to make the following changes in
presentation:

 - For GET, GETF, and GETHASH (and any others where it occurs), change
   "ignored by SETF" to "ignored by the SETF expander function for <fn>".

 - In the description of SETF, add wording saying:

   Some place forms involve uses of accessors which take optional arguments. 
   Whether those optional arguments are permitted by SETF, or what their use
   will be, is up to the SETF expander function and is not under the control
   of SETF. The documentation for any function which accepts optional, rest,
   or keyword arguments and which claims to be usable with SETF must specify
   how those arguments will be treated.