[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
setf subseq question
Date: Fri, 8 Jan 88 00:03 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Pg. 248: subseq sez
"
setf may be used with subseq to destructively replace a subsequence with a
sequence of new values; see also replace.
"
I ignore replace, because it says see also, as in another function that
does something along these lines, not see that for the definition of what
the setf does...
so what should (setf (subseq "abcdef" 3 5) "z")
do?
The answer is on page 95, near the bottom of the page. It changes
the constant "abcdef" to "abczef". CLtL suffers from poor cross-referencing.
I would say (and vote for) "abcz" but if it acts like replace, you get
"abczef".
There is no way SETF could change the length of the sequence if it was not
either an adjustable array or one with a fill-pointer.
It would be real nice to have a (destructive) function that can replace
sequences with other sequences..., e.g. like substitute where new-item is
new-sequence.
I think you mean a function that is to SUBSTITUTE as SEARCH is to POSITION.
I agree that this is useful; of course, it's not hard to write for yourself
if you don't care about machine-dependent efficiency optimizations.
Date: Fri, 8 Jan 88 00:26 EST
From: Barry Margolin <barmar@Think.COM>
The point of SETF is that after doing
(progn (setf <form> <val>)
<form>)
should return <val> (assuming that <form> doesn't have side-effects that
alter its return value). If the result were "abcz" then (subseq
<result> 3 5) is an error. If the result were "abczef" (which is what
Symbolics returns) then (subseq <result> 3 5) returns "ze", which isn't
the same as "z".
It's true that the way CLtL defines SETF of SUBSEQ violates that aphorism
about setf. I don't see any way to define it that would be consistent
with the aphorism, other than to forbid the two lengths to differ. I'm
not going to defend the current definition of SETF of SUBSEQ as right;
in this message I'm just telling you what CLtL says.