From: Roland Winkler <Roland.Winkler@physik.uni-erlangen.de>
Subject: Re: replacing a certain element in a list with another
Date: 24 Oct 2003 14:02:15 +0200 [thread overview]
Message-ID: <m3ptgmdet4.fsf@tfkp07.physik.uni-erlangen.de> (raw)
In-Reply-To: SuYlb.208$lK3.3@news.level3.com
Barry Margolin <barry.margolin@level3.com> writes:
> The verbose documentation of all the destructive list operations should
> mention that you must use the value to get the expected results all the
> time, rather than depending on everything to work due to the lists being
> modified in place.
The first part of your sentence is exactly my point. Unlike the
docstring of nreverse, the info node presently does not say
explicitely that it is the _return_ value that should be used. (It
is hidden only implicitely in the sentence: "To avoid confusion, we
usually store the result of `nreverse' back in the same variable
which held the original list.")
The info node Rearrangement in the elisp manual says:
- Function: nreverse list
This function reverses the order of the elements of LIST. Unlike
`reverse', `nreverse' alters its argument by reversing the CDRs in
the cons cells forming the list. The cons cell that used to be
the last one in LIST becomes the first cons cell of the value.
For example:
(setq x '(a b c))
=> (a b c)
x
=> (a b c)
(nreverse x)
=> (c b a)
;; The cons cell that was first is now last.
x
=> (a)
The last two lines I find confusing because they use the argument of
nreverse after it was passed to nreverse. (They gave rise to my
question whether the argument of nreverse could be used for anything
"useful" after it was passed to nreverse.) Instead, the info node
could use the same sentence that is used in the docstring of nreverse:
Returns the beginning of the reversed list.
next prev parent reply other threads:[~2003-10-24 12:02 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-30 8:38 replacing a certain element in a list with another Klaus Berndl
2003-09-30 9:05 ` David Kastrup
2003-09-30 9:59 ` Klaus Berndl
2003-09-30 10:03 ` David Kastrup
2003-09-30 10:19 ` Klaus Berndl
2003-09-30 12:12 ` Pascal Bourguignon
2003-09-30 14:14 ` Stefan Monnier
2003-09-30 14:26 ` Klaus Berndl
2003-09-30 14:16 ` Stefan Monnier
2003-09-30 14:28 ` Klaus Berndl
2003-09-30 15:03 ` Stefan Monnier
2003-09-30 15:30 ` Kevin Rodgers
2003-09-30 15:47 ` Stefan Monnier
2003-09-30 18:27 ` Roland Winkler
2003-09-30 20:01 ` Barry Margolin
2003-10-16 20:52 ` Kai Grossjohann
2003-10-22 20:06 ` Roland Winkler
2003-10-22 20:32 ` Barry Margolin
2003-10-23 12:46 ` Roland Winkler
2003-10-23 14:25 ` Stefan Monnier
2003-10-23 15:30 ` Kevin Rodgers
2003-10-23 15:18 ` Barry Margolin
2003-10-23 22:03 ` Roland Winkler
2003-10-23 22:20 ` Barry Margolin
2003-10-24 12:02 ` Roland Winkler [this message]
2003-10-24 15:06 ` Barry Margolin
2003-10-25 11:25 ` Oliver Scholz
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3ptgmdet4.fsf@tfkp07.physik.uni-erlangen.de \
--to=roland.winkler@physik.uni-erlangen.de \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).