SETF of pathname components

[Robert W. Kerns <RWK@SCRC-YUKON.ARPA>]

    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

(PATHNAME-NAME *BAR*)

to return?

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?