[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
- To: masinter.pa@Xerox.COM
- Subject: Re: Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 1 Feb 89 15:21 EST
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: <890201-115027-10967@Xerox>
Date: 1 Feb 89 11:48 PST
??? 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
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
- 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.