From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Newsgroups: gmane.emacs.bugs Subject: bug#43557: 28.0.50; Please document which objects are mutable and which are not Date: Fri, 4 Jun 2021 15:56:12 +0200 Message-ID: <6F14B065-611C-4ACE-BBD5-50B34512C00B@gmail.com> References: <87mu0nv6y6.fsf@gnus.org> <78C74FCB-EAEF-4E9F-9C79-3A2178FA60FE@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31088"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 43557@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 04 15:57:12 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1lpAJy-0007pV-7X for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Jun 2021 15:57:10 +0200 Original-Received: from localhost ([::1]:33054 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpAJw-0005t5-Vh for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Jun 2021 09:57:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41476) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpAJq-0005sh-BC for bug-gnu-emacs@gnu.org; Fri, 04 Jun 2021 09:57:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36062) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lpAJq-00042y-2O for bug-gnu-emacs@gnu.org; Fri, 04 Jun 2021 09:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lpAJp-00035g-Uu for bug-gnu-emacs@gnu.org; Fri, 04 Jun 2021 09:57:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Jun 2021 13:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43557 X-GNU-PR-Package: emacs Original-Received: via spool by 43557-submit@debbugs.gnu.org id=B43557.162281498911776 (code B ref 43557); Fri, 04 Jun 2021 13:57:01 +0000 Original-Received: (at 43557) by debbugs.gnu.org; 4 Jun 2021 13:56:29 +0000 Original-Received: from localhost ([127.0.0.1]:47605 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpAJF-00033e-Gn for submit@debbugs.gnu.org; Fri, 04 Jun 2021 09:56:29 -0400 Original-Received: from mail-wr1-f51.google.com ([209.85.221.51]:40909) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpAJ9-00032y-Ur for 43557@debbugs.gnu.org; Fri, 04 Jun 2021 09:56:23 -0400 Original-Received: by mail-wr1-f51.google.com with SMTP id y7so4779007wrh.7 for <43557@debbugs.gnu.org>; Fri, 04 Jun 2021 06:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ohTCFXG4RMGhse8PY2gzFwG9d/e8zRJEZV9GkFAJBZM=; b=UPhcxoO1K3dUkQCov9aotFC7yT/Bw/8Miw8LMx4e8FHd+BzZg8Pd8fmyNTb+SEjdc/ UGkZwUgLJBwIbEsVSBivjQWkFzKw+oxHkPic3UtE1/QrWYzwkrwYvLQKSXIkR+WoXCkO 4hVHE7cLhN1htrqUKX8Qf7b4LQxFimcmNJ0DNqYhKvTb+svTEcxxEUG9RhN+/Psp9jq+ nxIxiEyJSuaG6le7Fv2iiIx4VqO4tmngIhsGm6OrZ7yK50vOEWj95i6A4RxP3lYsOQkg YOC1GU5X6CdoH9kNKL1cBqw8ZZsHrb3vYF/PSlKOll3noh9qQvzTujWfi1u506LzylhE GQ3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ohTCFXG4RMGhse8PY2gzFwG9d/e8zRJEZV9GkFAJBZM=; b=aAQOva05YhhtM0GaXibdkeqTroMjGzXeA6wz/vBXgjQIKIfW3JNI+Sb7ah7F7a1Bgz lj2dctls7yBn/S3w4A/jJhuJOjucqbSheEhM7cRIKlnWB47w5sBL4TtcfVRXqkt2AEhK vz5i2OLeLDhlK9rjkA7AMhkpV61Q1vmuMCv+ACQ9g68GoG4Z8UQVIcQhFeC1WAR4STOf FE8Te+iZ9wykTx0cRfxfVNLexqiuFT8AgJnrxRaZNXRdeI4liN5dtvMsNra9B/ANQGZV oYgnIUkVlsefblKt+xwIrF2NOBTtqpluu1h6gVZMmcbBSprAoG2YeH2z8Fg6p8EPzJH8 D5Jg== X-Gm-Message-State: AOAM530cB8H8oWJr/jxu6XTvj+SiB9OrBcSY2abjH3Qt8+s1mi/jIWNt DV9jVZw1iTqCS9xbos2796g= X-Google-Smtp-Source: ABdhPJzEc9sA/mzTCWdyLClykLhWC2dD7X5qgzRJ2PrzRTTWwTCAQg4xe5ewNUb2dV9MqnEkm02MtA== X-Received: by 2002:a5d:65cd:: with SMTP id e13mr4083789wrw.93.1622814973883; Fri, 04 Jun 2021 06:56:13 -0700 (PDT) Original-Received: from smtpclient.apple ([46.128.198.100]) by smtp.gmail.com with ESMTPSA id j14sm8833551wmi.32.2021.06.04.06.56.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Jun 2021 06:56:13 -0700 (PDT) In-Reply-To: <78C74FCB-EAEF-4E9F-9C79-3A2178FA60FE@gmail.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:208017 Archived-At: > Am 04.06.2021 um 15:01 schrieb Philipp : >=20 >=20 >=20 >> Am 03.06.2021 um 16:41 schrieb Stefan Monnier = : >>=20 >>> I disagree. "Pretty clear" would mean "allowing the reader to = classify >>> each Lisp expression w.r.t. the mutability of its value", and as the >>> section only gives a few examples, it can't do that. What it should = do >>> in addition is provide rules on how to classify any given Lisp >>> expression. Each possible Lisp expression has to fall into exactly = one >>> of three categories: >>> - The value is mutable. >>> - The value is immutable. >>> - It is unspecified whether the value is mutable or immutable. >>=20 >> While I can kinda see where you're going, it's still pretty fuzzy to = me. >> I think it would be more clear if you could give concrete cases where >> you'd want to use such information. >=20 > I don't know how concrete a case you want here, but basically I'd like = the manual to describe the semantics of >=20 > (let ((var FORM)) (setcar var VAL)) >=20 > for arbitrary values of FORM (assuming that FORM returns a cons = object). Likewise for `aset', `set', and the other object-mutating = primitives. > What the semantics of such a form are depends crucially on the = mutability of the value returned by FORM: if FORM returns an immutable = object, then the overall form triggers undefined behavior. In other = words, the manual needs to provide a procedure to classify forms = according to the mutability of their return values. To provide a more concrete example: Assume you have the following (nonsense) function, with unknown = implementation: (defun my-cons () "Return a cons cell consisting of the integers 1 and 2." ...) I. Given only that information and the manual, is the following code = valid (i.e. can't trigger undefined behavior in any case)? (setcar (my-cons) 5) II. Which of the following implementations of `my-cons' is correct (i.e. = follows the rules of Emacs Lisp as described in the manual)? (a) (defun my-cons () "Return a cons cell consisting of the integers 1 and 2." '(1 . 2)) (b) (defun my-cons () "Return a cons cell consisting of the integers 1 and 2." (cons 1 2) (c) (defun my-cons () "Return a cons cell consisting of the integers 1 and 2." (if (eq (random 2) 0) '(1 . 2) (cons 1 2)) =46rom what I can see there are four options: 1. Unless otherwise specified, objects are mutable. Then the `setcar' = form is valid, and only implementation (b) is correct. 2. Unless otherwise specified, objects are immutable. Then the `setcar' = form always triggers undefined behavior, and only implementation (a) is = correct. 3. Unless otherwise specified, the objects that forms return are of = unspecified mutability (i.e. they can be mutable or immutable). Then = the `setcar' form is invalid because the caller of `my-cons' can't = assume that its return value is mutable, and all three implementations = of `my-cons' are correct. 4. Mutability of the return object must be specified in all cases. Then = none of the implementations is correct, since none of them specifies the = mutability of the returned cons object. What I'd like here (among other things) is a statement in the manual = which of the options (1)-(4) is the correct one. (Or are there other = options?)=