From: Drew Adams <drew.adams@oracle.com>
To: "João Távora" <joaotavora@gmail.com>
Cc: 33998@debbugs.gnu.org, Deus Max <deusmax@gmx.com>
Subject: bug#33998: 27.0.50; cl-delete does not delete the first list element
Date: Tue, 8 Jan 2019 11:07:03 -0800 (PST) [thread overview]
Message-ID: <bc7ef6c0-2cc5-4b13-b40b-7f7368abd586@default> (raw)
In-Reply-To: <CALDnm53KOymAEghHTYNvNnDo231Na4AV9LpLtD6g6CY+EYwonA@mail.gmail.com>
> > Without setting variable `seq' (i.e., without
> > the `setq'), that variable is still bound to
> > whatever it was bound to prior to your invoking
> > `(cl-delete thing seq)'. Presumably it was
> > bound to a cons.
>
> It could have been bound to a vector. cl-delete (as delq, delete)
> accepts sequences. And contrary to those two, it makes
> no guarantees as to how it potentially destroys the original
> sequence. So unless you're relying on a particular
> implementation, relying on SEQ after calling cl-delete on it
> is a bad, bad idea.
>
> So yes, always (setq SEQ (cl-delete THING SEQ)). With
> the extraordinary exception that you're leaving the scope
> where SEQ is visible. Then you can bypass it.
I'm repeating myself, so I'll stop here.
You are _not_ "calling cl-delete on it", where "it"
is the variable SEQ. You are calling the function
on its value, whether that value is a vector, a
list or any other kind of sequence. `cl-delete'
never sees, smells, or hears the variable.
It all depends what a user intends by "relying on
SEQ". If you ALWAYS mean relying on its value to
be what `cl-delete' returns then sure, clearly you
must ALWAYS set it to that return value. If in
some case you instead mean relying on it not to be
affected by `cl-delete' then you won't want to
assign it to the result of invoking `cl-delete'.
It's not about implementation of `cl-delete'. It's
not about the type of sequence you pass it. It's
about a variable being something different from its
value.
next prev parent reply other threads:[~2019-01-08 19:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-06 13:30 bug#33998: 27.0.50; cl-delete does not delete the first list element Deus Max
2019-01-07 17:13 ` João Távora
2019-01-07 17:28 ` Drew Adams
2019-01-07 18:04 ` João Távora
2019-01-07 18:14 ` Drew Adams
2019-01-08 13:45 ` João Távora
2019-01-08 18:22 ` Drew Adams
2019-01-08 18:31 ` João Távora
2019-01-08 18:45 ` Drew Adams
2019-01-08 18:57 ` João Távora
2019-01-08 19:07 ` Drew Adams [this message]
2019-01-08 21:38 ` João Távora
2019-01-09 1:30 ` Drew Adams
2019-01-07 20:20 ` Deus Max
2019-01-07 20:27 ` Dmitry Gutov
2019-01-07 20:48 ` Deus Max
2019-01-07 21:06 ` João Távora
2019-01-07 22:46 ` Deus Max
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=bc7ef6c0-2cc5-4b13-b40b-7f7368abd586@default \
--to=drew.adams@oracle.com \
--cc=33998@debbugs.gnu.org \
--cc=deusmax@gmx.com \
--cc=joaotavora@gmail.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).