From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs 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) Message-ID: <28b51c37-42c5-4196-b970-03ed8e55ce49@default> References: <87muodud4d.fsf@aia00054aia.gr> <39367b1c-ea27-4627-99e3-eb7d0745c60f@default> <87muoaltiu.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1546997345 23314 195.159.176.226 (9 Jan 2019 01:29:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 9 Jan 2019 01:29:05 +0000 (UTC) Cc: 33998@debbugs.gnu.org, Deus Max To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 09 02:29:00 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gh2g0-0005vv-M5 for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Jan 2019 02:29:00 +0100 Original-Received: from localhost ([127.0.0.1]:60098 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gh2i7-00060d-B4 for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Jan 2019 20:31:11 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gh2hz-0005zZ-Pk for bug-gnu-emacs@gnu.org; Tue, 08 Jan 2019 20:31:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gh2hy-00072k-Ma for bug-gnu-emacs@gnu.org; Tue, 08 Jan 2019 20:31:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51475) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gh2hy-00072e-Hg for bug-gnu-emacs@gnu.org; Tue, 08 Jan 2019 20:31:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gh2hy-0001Rf-7u for bug-gnu-emacs@gnu.org; Tue, 08 Jan 2019 20:31:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jan 2019 01:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33998 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 33998-submit@debbugs.gnu.org id=B33998.15469974223334 (code B ref 33998); Wed, 09 Jan 2019 01:31:02 +0000 Original-Received: (at 33998) by debbugs.gnu.org; 9 Jan 2019 01:30:22 +0000 Original-Received: from localhost ([127.0.0.1]:50756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gh2hK-0000rF-9L for submit@debbugs.gnu.org; Tue, 08 Jan 2019 20:30:22 -0500 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:46490) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gh2hH-0000h2-QV for 33998@debbugs.gnu.org; Tue, 08 Jan 2019 20:30:20 -0500 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x091OTim122555; Wed, 9 Jan 2019 01:30:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=Rb90/YJOdOUc9K8RQWmM5GTLsCzQ1W8URhY2DSVjwHQ=; b=k677TXc2iQfMf9qKFA6lCq1AOE6fWRT2EI1InKDVzNbSfnGIsqEuHFiupVDrOVwBJmCt fqN9tJjuEIT9RS+sf76vmjmOEMe9yyxUrMAeFO4933RKwVRUTVEv9r6fO5D2NC4wyGah FHJHLCcH+Ll5jSh/e0bNvpkvZNWpi3jZiWMkA8K7pZjpxeBUkjDcl8nBWWXK8UADCv7f xdSblmtF3F+DoVpgBZA1l0lDUeyPLWUwLbtcOhRDuo/e5aNGyITvQQihSgyAP3XZcR2L f8GrAG4XnphAbeJT9UX896vrp4P0qXgGmYpgCLG1eXUhqCJCOwzcOPHVjP8AgTy1E9Jq gA== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2ptj3dy0n5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 09 Jan 2019 01:30:13 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x091UBSZ023071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Jan 2019 01:30:12 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x091UBGH007636; Wed, 9 Jan 2019 01:30:11 GMT In-Reply-To: <87muoaltiu.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4783.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9130 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=895 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901090008 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:154283 Archived-At: > > 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. >=20 > Drew, it is you who are missing something basic here: >=20 > (defun mistery (thing seq) > (let ((head (elt seq 0))) > (cl-delete thing seq) > (eq head (elt seq 0)))) >=20 > 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' >=20 > (mistery 1 (list 1 2 3 4)) ;; =3D> t > (mistery 1 (vector 1 2 3 4)) ;; =3D> 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.