bug#12314: 24.2.50; `add-to-history': use `setq' with `delete'

[Drew Adams]

> > My gripe was only about using the term "destructive
> > modification", which muddies the waters without gaining anything.
> 
> I don't know, to me "destructive modification" sounds like a 
> very clear term explaining the general kind of danger we're up
> against (the kind that's summarized in Scheme by adding a "!" at
> the end of the identifier).

The term itself does not _explain_ the danger, but it does suggest some danger.

Strictly speaking, "destructive modification" is redundant - all modification
replaces one state by another: it destroys an old state and creates a new one.

But Lisp being entre deux chaises (functional, imperative/procedural), and given
the existence of similar-sounding Lisp functions such as `remove' and `delete',
it is worth emphasizing the difference (for the doc of both `remove' and
`delete').

For the non-modifying one, we point out explicitly that it is "non-destructive".
For the modifying one, we point out explicitly that it modifies something, as a
side effect, and we (conventionally, in Lisp jargon) call it "destructive".

It's about the doc being not only correct but also more helpful.  Sometimes a
bit of redundancy has pedagogical merit.  Sometimes redundancy is just noise to
wade through.  Here, specifically because of the "danger"/gotchas, it does not
hurt to add "destructive", IMO.

It is really the names of "non-destructive" functions such as `append' and
`remove' that are misleading.  They necessitate our taking pains to explain that
no real modification takes place.  Names that better suggest the declarative
nature of such functions might be, say, `concatenation' and `all-but' (or
`removed').

Names such as `append' and `remove' do not describe the result value of the
function.  Instead, they describe a modifying operation that might have nothing
to do with the actual implementation (which is not so important here anyway),
and they take emphasis away from what is important for a pure function: the
return value.

But such procedurally oriented naming is pretty common/traditional, even for
applicative languages.  And it tends toward shorter, simpler names.