[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SETF-FUNCTION-VS-MACRO (Version 2)
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: SETF-FUNCTION-VS-MACRO (Version 2)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 4 Nov 87 14:17 EST
- Cc: Masinter.pa@Xerox.COM, CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: <871029151550.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
- Line-fold: No
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:
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
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
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
* 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.
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".