[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.