all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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










  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.