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 17:30:10 -0800 (PST) [thread overview]
Message-ID: <28b51c37-42c5-4196-b970-03ed8e55ce49@default> (raw)
In-Reply-To: <87muoaltiu.fsf@gmail.com>
> > 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.
>
> Drew, it is you who are missing something basic here:
>
> (defun mistery (thing seq)
> (let ((head (elt seq 0)))
> (cl-delete thing seq)
> (eq head (elt seq 0))))
>
> Today, in Emacs this always returns t, for every THING and sequence SEQ
> you can think of (in fact, for vectors, cl-delete delegates to cl-remove).
> This is perfectly CL-compliant. But a future, different, also perfectly
> CL-compliant, implementation of cl-delete, might very well make this
> function return nil. In fact, if you port this code to SBCL or Allegro
> CL by changing 'cl-delete' to 'cl:delete'
>
> (mistery 1 (list 1 2 3 4)) ;; => t
> (mistery 1 (vector 1 2 3 4)) ;; => nil
Your example has no bearing on our discussion,
AFAICT.
What is passed to your function are two values -
no variables. Again, `cl-delete' sees only a
sequence value, not any _variable_ that might
have that sequence as its variable. And yes,
that's by design. `cl-delete' can change the
elements of a sequence (a value), but it cannot
change the value of a variable. That's not its
job.
> So again, for the nth time, it's a bad idea to rely on SEQ after calling
> 'cl-delete'.
Again, you are confusing `SEQ' the variable with
its value. There is no such general rule with
"always" as part of it. Not in Lisp, there ain't.
If that were not the case then you would be in
effect claiming (and perhaps you are explicitly
claiming) that CL's definition of `delete' is a
bad one, misguided, since it applies only to a
sequence and not to any variable that might have
that sequence as its value.
Contrast Lisp functions such as `delete' and
`nconc' to a Lisp function such as `add-to-list'
or to a special form (or macro) such as `push'.
The latter act on a _variable_ (possibly a
generalized variable - a place). `delete',
`nconc' etc. do NOT act on a variable.
If you really believe "always" to apply then you
had better toss all of the functions that possibly
modify values, replacing them with only macros or
special forms that (like `push') set a variable
(place) to its modified value or to functions that
(like `add-to-list') accept a variable (symbol)
as argument and set it to its modified value.
Such things are available in Lisp, and you can
define more such. But Lisp doesn't _limit_ itself
to such things - IOW, Lisp does NOT say "always".
Why? For the reasons I gave - sometimes you don't
want to update a variable. IOW, "always" is not
always the case - it just isn't.
I already said I'd stop. I hope that's the case
now, at least. Perhaps we can agree to disagree:
you say "always"; I say "often".
You (apparently) think there's no reason for a
function such as `cl-delete', and that it would be
better for Lisp itself to enforce your "always"
rule, using either a macro or a function that
takes a symbol argument rather than just a value.
Any programmer can certainly do that. Lisp offers
both possibilities.
next prev parent reply other threads:[~2019-01-09 1:30 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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=28b51c37-42c5-4196-b970-03ed8e55ce49@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 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.