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