From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Teemu Likonen Newsgroups: gmane.emacs.devel Subject: Re: inverse of add-to-list: remove-from-list Date: Wed, 14 Oct 2020 08:28:15 +0300 Message-ID: <878sc9fkb4.fsf@iki.fi> References: <20201013193400.uqm2ng6rgfnsei2w@E15-2016.optimum.net> <87pn5mtt2x.fsf@mat.ucm.es> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36963"; mail-complaints-to="usenet@ciao.gmane.io" To: Boruch Baum , Emacs-Devel List Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 14 07:33:15 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kSZPW-0009Tc-C5 for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 07:33:14 +0200 Original-Received: from localhost ([::1]:54142 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSZPV-0001kJ-6j for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 01:33:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59262) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSZKy-0000oV-KV for emacs-devel@gnu.org; Wed, 14 Oct 2020 01:28:32 -0400 Original-Received: from lahtoruutu.iki.fi ([185.185.170.37]:55750) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSZKu-0005F8-GW for emacs-devel@gnu.org; Wed, 14 Oct 2020 01:28:32 -0400 Original-Received: from mithlond (mobile-access-bcee8a-95.dhcp.inet.fi [188.238.138.95]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: tlikonen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id E491F1B00193; Wed, 14 Oct 2020 08:28:22 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1602653303; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=q0TEHXjqaSx+kARhoKac+s1N6ow44oMB5nUHByWzT68=; b=v6dlLlUAi2ZFB6uC1ye1Nf9Ib0frwif2ig8bVEpR1etU89lLG4PZe2Hw0n5zJOMoujCHl9 7GRL0sDK5wCJ9hREH6LEJwdlxH0muJwM2z0orJNnB61oihUZU8WVyphb0KI+/MrDt7sjeL skCaQfuI8dYpQmgjI2UBVxGZ0mrv16RbId6RMnS/DrYWtODB+HdVeJyINxBlb1HrsBLfy2 9Z0IWHFye3Kk7IqKvV2JgJImWYANj7DawwHbVrDQQEQqPSZha3OzvzZ3xYi6NmmZjBqVow 84REEwGRQnhxc1ZcmN7LljSHqZ7Xehqr+SmeL5iueu+FYLEUsaBzBcS6GIr9yw== In-Reply-To: <20201013193400.uqm2ng6rgfnsei2w@E15-2016.optimum.net> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1602653303; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=q0TEHXjqaSx+kARhoKac+s1N6ow44oMB5nUHByWzT68=; b=GEV06De/mT6Q/iMaBiMIZQtRa0AB3RZqZ06RgVf3qQIfxBxFDyxCvZXZifUJPvbAeiAlbb XaRsTkiJ+M57w42KkkQo7GxoUuplRa5iDdBdFsXRZ4yaDn9rrazJeJ1fEGlgyC33DeP1Wy JLtrjQPWS0ykK53qHCAuZq7gumCf9p1EMctPe45avMnNTOz6TKjoSoLDZi3Xmqp4x2J5vo sT9wql29wRXXVrYL4J0IhFLPL4KTE8wS2PH34i706ckDid+NLouV9h/uoBncUYbK7qJBVp KfYrVa3WTv4Si6ZrLfzg8+vFq8udF6wrRucn1PhUr+SdQvAziDYQwdTisJY9JQ== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1602653303; a=rsa-sha256; cv=none; b=QJ1PconBOJ+ZWJJJta20vL7RHivSx7K6HsrTCshd703V2cLktvzvE2eUxsKjGT0OB34szp BXt+wuO0PEiCXuUR0lqIrbtv9ExTJ0aVWDwY2CQeVwqiJ0w4B9yY3UMDtuRz2mE1Aw1BcM bf9236SoyfDfg+ZvKLmKGcOpdc6b+8r2TGaLguSzihPlfxq1rgH3vIOJj7TEfBeBXecPJP cgL88bwm2mQ8qGEl4v+nZrinW1fw3oma1qTd90OZ7+eutPQZkB+Bx3UFm73HJIwyDubGZw dJZgDDN06hBMHXJ/QwbHUeAhkIgrF6QnhD2vIWDLsTIZQ7cTfuX17gs/7rU8Fw== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=tlikonen smtp.mailfrom=tlikonen@iki.fi Received-SPF: pass client-ip=185.185.170.37; envelope-from=tlikonen@iki.fi; helo=lahtoruutu.iki.fi X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/14 01:28:23 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:257612 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable * 2020-10-13 15:34:00-04, Boruch Baum wrote: > (let ((aa '(1 2 3 1 4 1 2))) > (delete 2 aa) > aa) In Lisp world it is not recommended to use destructive operations like DELETE for literal objects like list created with QUOTE operator '(1 2) or a string created with quotation marks ("abc"). Compilers can create a single object for all literally defined object. Emacs Lisp manual "(elisp) Equality Predicates" says: The Emacs Lisp byte compiler may collapse identical literal objects, such as literal strings, into references to the same object, with the effect that the byte-compiled code will compare such objects as =E2=80=98eq=E2=80=99, while the interpreted version of the same code wi= ll not. For example: (defvar foo '(1 2 3)) (let ((bar '(1 2 3))) (eq foo bar) ; This may return T. (setq bar (delete 3 bar))) ; This may also modify FOO. So, using a destructive operation for a literal object may change it everywhere. To create a modifiable objects we should use LIST, MAKE-LIST, MAKE-STRING, COPY-SEQUENCE, CL-COPY-SEQ, for example. > And note that the fine distinction made in the docstring for the > `delete' function: > > "If SEQ is not a list, deletion is never performed destructively; > instead this function creates and returns a new vector or string. > > Write =E2=80=98(setq foo (delete element foo))=E2=80=99 to be sure = of correctly > changing the value of a sequence =E2=80=98foo=E2=80=99. > > So, in the case of SEQ being a list, there is no need to `setq foo'. In Lisp manuals "destructive" means that the operation may modify the original object given as an argument. It doesn't promise anything else. Sometimes the original object is modified, sometimes it is not. Even if the original object is modified it doesn't promise that it's the same as the return value of a destructive function. The original object and the return value can be partially the same: lists may share some cons cells. We must always use the return value of a destructive function. =2D-=20 /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iIYEARYIAC4WIQTJW2wqtelxC1gHdbitnXWr7pTCcwUCX4aMbxAcdGxpa29uZW5A aWtpLmZpAAoJEK2ddavulMJzS2kBAKJ3A+g3o1jkgEQob1mBJlLckUeoSsdZgILQ x5x7pfKUAP485h78BDU0KoP/1GomUJ1TToWVgpl+TcAd6Y1whrEyCQ== =+cZv -----END PGP SIGNATURE----- --=-=-=--