unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





  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

  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=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 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).