[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SETF of pathname components
Date: Tue, 15 Oct 85 18:23:24 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Date: Tue, 15 Oct 85 15:25 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
For uniformity we could extend this to other read-only accessors
like SYMBOL-NAME, and DENOMINATOR although it's hard to see it as
useful in the former case, and it's pretty strange in the later
(and probably indicative of a woefully ineffecient program).
I agree with Moon's analysis, but i disagree that on these grounds
SETF should handle pathname components like LDB handles integers. I
don't think pathnames appear to be sufficiently non-structured that
the read-only-ness of the components should be taken advantage of
in order to permit this hack.
I didn't understand this at first, but let me take a stab
at guessing (and explaining) what you mean.
SETF of LDB replies on the fact that you "obviously" can't
store into integers to make it clear that the side effect
must be happening not to the integer but to the location
containing the integer.
However, using the "SETF of LDB" technique can be confusing:
Consider what happens when you have, say, a pathname, stored
in two variables *FOO* and *BAR*. You do
(SETQ *FOO* (SETQ *BAR* (MAKE-PATHNAME :HOST "CROW")))
(SETF (PATHNAME-NAME *FOO*) "YOW")
What would you expect
In this regard, I guess SETF of LDB is a wart on the language,
really an entirely different syntactic entity using the same
syntax. Expanding this overlap can only add to the problem.
The same goes for symbol-name. As for denominator, it sounds
sufficiently ludicrous that i think it also should be left out, but
only because it seems perverse.
Actually, I think my interpretation of your argument above
applies here, too.
Is this what you were arguing?