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

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>, "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 12314 <at> debbugs.gnu.org, cyd <at> gnu.org
Subject: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete'
Date: Mon, 10 Sep 2012 08:21:57 -0700

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.