From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>,
"'Eli Zaretskii'" <eliz@gnu.org>
Cc: 12314@debbugs.gnu.org, cyd@gnu.org
Subject: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete'
Date: Mon, 10 Sep 2012 08:21:57 -0700 [thread overview]
Message-ID: <94A9E1848B7F45A0A185CA689FA724C4@us.oracle.com> (raw)
In-Reply-To: <jwv8vcijaqc.fsf-monnier+emacs@gnu.org>
> > 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.
next prev parent reply other threads:[~2012-09-10 15:21 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-30 23:08 bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Drew Adams
2012-09-08 14:32 ` Chong Yidong
2012-09-08 14:43 ` Eli Zaretskii
2012-09-08 14:57 ` Drew Adams
2012-09-08 15:20 ` Eli Zaretskii
2012-09-08 15:48 ` Drew Adams
2012-09-08 16:05 ` Eli Zaretskii
2012-09-08 16:19 ` Andreas Schwab
2012-09-08 16:33 ` Eli Zaretskii
2012-09-08 16:50 ` Lars Ingebrigtsen
2012-09-08 16:54 ` Drew Adams
2012-09-08 17:06 ` Andreas Schwab
2012-09-08 16:35 ` Drew Adams
2012-09-08 16:25 ` Drew Adams
2012-09-08 16:32 ` Eli Zaretskii
2012-09-08 16:42 ` Drew Adams
2012-09-08 21:21 ` Eli Zaretskii
2012-09-08 22:26 ` Drew Adams
2012-09-09 3:00 ` Eli Zaretskii
2012-09-09 6:29 ` Drew Adams
2012-09-09 7:53 ` Chong Yidong
2012-09-09 17:25 ` Eli Zaretskii
2012-09-10 11:54 ` Wolfgang Jenkner
2012-09-08 23:11 ` Stefan Monnier
2012-09-09 2:51 ` Eli Zaretskii
2012-09-09 14:44 ` Stefan Monnier
2012-09-09 17:14 ` Eli Zaretskii
2012-09-09 17:35 ` Drew Adams
2012-09-09 18:20 ` Eli Zaretskii
2012-09-09 19:46 ` Drew Adams
2012-09-09 21:37 ` Stefan Monnier
2012-09-10 4:37 ` Eli Zaretskii
2012-09-10 12:59 ` Stefan Monnier
2012-09-10 15:01 ` Stefan Monnier
2012-09-10 15:21 ` Drew Adams [this message]
2012-09-10 16:24 ` Eli Zaretskii
2012-09-09 8:25 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=94A9E1848B7F45A0A185CA689FA724C4@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=12314@debbugs.gnu.org \
--cc=cyd@gnu.org \
--cc=eliz@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.