From: "João Távora" <joaotavora@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>
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: Mon, 07 Jan 2019 21:06:44 +0000 [thread overview]
Message-ID: <87a7kcmb2z.fsf@gmail.com> (raw)
In-Reply-To: <219daf3c-1341-a2aa-6d0e-6388c4a3184b@yandex.ru> (Dmitry Gutov's message of "Mon, 7 Jan 2019 23:27:34 +0300")
Dmitry Gutov <dgutov@yandex.ru> writes:
> On 07.01.2019 23:20, Deus Max wrote:
>> The variable you pass is modified.
>
> The value. Not the variable. The latter keeps pointing at whatever
> cons it's pointed before.
What Dmitry said, let me just add this: what you call variables in Lisp
are actually symbols that, among other things, may (or may not) have a
"variable binding" (this is why you sometimes get "unbound" errors when
you try to evaluate a symbol's variable value). They are indeed
pointers.
So if you read "destructive" as in "modify a variable's binding,
i.e. the place where it points to" then no *function* can do that when
passed the variable, because what it is receiving is the value pointed
to by the symbol. A macro, like 'setq' or 'pop' can do that, because it
"sees" the symbol.
An alternative place to read on Common Lisp's DELETE is Common Lisp's
hyperspec:
http://www.lispworks.com/documentation/HyperSpec/Body/f_rm_rm.htm
The "may modify sequence" sentence figures prominently there.
Emacs's cl-delete attempts to emulate Common Lisp's CL:DELETE. In Emacs
it behaves, in this regard, no different from delete or delq. It is
"potentially destructive" because it *may* modify the *structure* of the
sequence *value* that you pass to it, be it a linked list or a vector:
1) If it is a linked list, it does the trick of making the pointer
before the element you want to delete point to the element after it;
2) If it is a vector, it moves all the vector elements after the one you
want to delete back one position and readjusts the vector size.
If you notice, for situation 2 you could theoretically affect the
variable binding directly. And curiously, this is where I found
differences between Emacs's cl-delete and some CL's implementation of
CL:DELETE.
Emacs:
(setq bla (vector 1 2 3 4))
(delete 1 bla) => [2 3 4]
bla => [1 2 3 4]
(setq bla (vector 1 2 3 4))
(cl-delete 1 bla) => [2 3 4]
bla => [1 2 3 4]
Allegro common lisp and CMU common lisp:
(setq bla (vector 1 2 3 4))
(delete 1 bla) => #(2 3 4)
bla => #(2 3 4)
SBCL common lisp:
(setq bla (vector 1 2 3 4))
(delete 1 bla) => #(2 3 4)
bla => #(2 3 4 4)
So, for vector sequences, CL:DELETE is apparently allowed to do
whatever. Reading the hyperspec, it seems that all these results are
correct, even SBCL's.
João
next prev parent reply other threads:[~2019-01-07 21:06 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
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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a7kcmb2z.fsf@gmail.com \
--to=joaotavora@gmail.com \
--cc=33998@debbugs.gnu.org \
--cc=deusmax@gmx.com \
--cc=dgutov@yandex.ru \
/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.