From unknown Fri Jun 20 05:35:00 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#43557 <43557@debbugs.gnu.org> To: bug#43557 <43557@debbugs.gnu.org> Subject: Status: 28.0.50; Please document which objects are mutable and which are not Reply-To: bug#43557 <43557@debbugs.gnu.org> Date: Fri, 20 Jun 2025 12:35:00 +0000 retitle 43557 28.0.50; Please document which objects are mutable and which = are not reassign 43557 emacs submitter 43557 Philipp Stephani severity 43557 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 22 04:29:34 2020 Received: (at submit) by debbugs.gnu.org; 22 Sep 2020 08:29:34 +0000 Received: from localhost ([127.0.0.1]:57099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKdg5-0002Uf-SA for submit@debbugs.gnu.org; Tue, 22 Sep 2020 04:29:34 -0400 Received: from lists.gnu.org ([209.51.188.17]:56410) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKdg1-0002UV-St for submit@debbugs.gnu.org; Tue, 22 Sep 2020 04:29:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51676) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKdg1-0003Cq-My for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2020 04:29:29 -0400 Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]:35351) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kKdfz-00071D-Sg for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2020 04:29:29 -0400 Received: by mail-ej1-x632.google.com with SMTP id u21so21655405eja.2 for ; Tue, 22 Sep 2020 01:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=WVVHOGyBHhIcrfz3V4yn+1Az3IrTJbeOBDK8DMBJC9c=; b=ZjYlCCYJKipMHPKsWswDdhUsHSYbJz3WXDjwV0BElLcJQ3anbOP9dVctC97RSGDLwX H/PdfuGy/z6DlvhCbuiuUSjVGtlTHYLUp0TLVcKTYNtJ56Ic5c4699lI08D0pQBbNEMB QiCrUOc7TAtCJwtelNmTnFQQR6dd+NUkdNJDt5G53sFVJkdTcoG7jRjHT2u/fs8xg9ZH xkDuozy3jPd2eMvEITtaUW+jRxjzfgZ6ZfwdSZEfmnR2Y5ueASBqZlZLsQTCpcmm7lzW Mk7s/wukufr5DDxyhqNsomHoEAPIQONQT8zi+QiJHYI3bKTGMegSNRLd29dBoI0f3X18 2GIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=WVVHOGyBHhIcrfz3V4yn+1Az3IrTJbeOBDK8DMBJC9c=; b=mjJtt4CEuz+G3rINKfO7h2BW+aSCZDPp8SngxOo2J/ad2Vc6CvXJ0VjkRSW1QjrMC7 UuUyIEjCIrnJNxQwvF8vONC458Lg+TtwXoV0Mca5hLO+0S5UjILxrEzBgOkfXQWoH8Yv ygpeKFJZzZmSfTc42WuNg8bgIDlsoBXbE7jEV14LbtUVY0+7KAMqKtl0vZ3cf8h19VTG J7vWDpJX1BP5KlhkqGO5fK/h/2MhuwkZcjHT5siWakh8eztBq7Zpm1ypiYezs48c34r2 f88pb33Lpp0FIe90xgHyHu10ewZeia+99ZyYISTcGaNLqGIfyJVgpENY/pMeAYOFmylP GL8A== X-Gm-Message-State: AOAM532M8hxQmFNQkC01ZfqFYzI8lMzNuiB31bWFDJH0njB7H3COg6F/ m7e5tbpIX0I016OYhE46rwOrNYZxilfZvQ== X-Google-Smtp-Source: ABdhPJz4wMRgwt6GcSq/PVJ/WkkTC7v5H04/tkYcRWjlpC21QW9qWxD9NMvrxtIghZzri33XF+RVJg== X-Received: by 2002:a17:906:82c1:: with SMTP id a1mr3623753ejy.270.1600763365470; Tue, 22 Sep 2020 01:29:25 -0700 (PDT) Received: from phst1 (p57aaf82a.dip0.t-ipconnect.de. [87.170.248.42]) by smtp.gmail.com with ESMTPSA id cf7sm10460702edb.78.2020.09.22.01.29.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Sep 2020 01:29:24 -0700 (PDT) From: Philipp Stephani To: bug-gnu-emacs@gnu.org Subject: 28.0.50; Please document which objects are mutable and which are not Date: Tue, 22 Sep 2020 10:29:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::632; envelope-from=p.stephani2@gmail.com; helo=mail-ej1-x632.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) The "Mutability" section in the ELisp manual mentions that there are mutable and immutable objects, but (besides giving a few examples) doesn't document which objects are actually mutable. At the very least, there should be a list of functions that are guaranteed to return mutable objects, and a statement about the mutability of function return values in general. In GNU Emacs 28.0.50 (build 106, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,= cairo version 1.16.0) of 2020-09-22 Repository revision: 797ff44d53ef4c4b800de8467b403c876cac3c1f Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12008000 System Description: Debian GNU/Linux rodete Configured using: 'configure --enable-gcc-warnings=3Dwarn-only --enable-gtk-deprecation-warnings --without-pop --with-mailutils --enable-checking=3Dall --enable-check-lisp-object-type --with-modules 'CFLAGS=3D-O1 -ggdb3 -fno-omit-frame-pointer -fsanitize=3Daddress -fsanitize=3Dundefined -fsanitize=3Dpointer-compare -fsanitize=3Dpointer-subtract'' Configured features: XPM JPEG TIFF GIF PNG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY LIBSELINUX GNUTLS FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON PDUMPER Important settings: value of $LANG: en_US.utf8 value of $XMODIFIERS: @im=3Dibus locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc dired dired-loaddefs rfc822 mml easymenu mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils phst skeleton derived edmacro kmacro pcase ffap thingatpt url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map url-vars mailcap rx gnutls puny dbus xml subr-x seq byte-opt gv bytecomp byte-compile cconv compile comint ansi-color ring cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 69082 7098) (symbols 48 8666 1) (strings 32 23937 1390) (string-bytes 1 771102) (vectors 16 13762) (vector-slots 8 188421 5360) (floats 8 26 30) (intervals 56 219 0) (buffers 992 11)) --=20 Google Germany GmbH Erika-Mann-Stra=C3=9Fe 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise erhal= ten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, l=C3=B6sche= n Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie mich bitte wissen, dass d= ie E-Mail an die falsche Person gesendet wurde. This e-mail is confidential. If you received this communication by mistake, please don=E2=80=99t forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 15 11:34:54 2020 Received: (at 43557) by debbugs.gnu.org; 15 Oct 2020 15:34:54 +0000 Received: from localhost ([127.0.0.1]:56253 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kT5HK-0007K7-3K for submit@debbugs.gnu.org; Thu, 15 Oct 2020 11:34:54 -0400 Received: from quimby.gnus.org ([95.216.78.240]:44436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kT5HI-0007Jt-HJ for 43557@debbugs.gnu.org; Thu, 15 Oct 2020 11:34:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=3zNXDLAr8mIQyT5GXum5YuwZMzek2HACdmBiJ27hIDo=; b=jruAZYcm0sIhelBZz3dPIkkRiG 6gPj/J5rH6oiAKq68TjnqO9ST5qCYkdMpCjM8LvjZOtDhF8hTWBcI5wcdEqMV2Hm31XDoftjDMMky DvM+vTGe81Rg2VWPLWvDYrwstQmKAxzWqyua9xyq0BXakMtEMaWlINhQa3wHVBRJNdFw=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kT5H8-0005pm-Kk; Thu, 15 Oct 2020 17:34:46 +0200 From: Lars Ingebrigtsen To: Philipp Stephani Subject: Re: bug#43557: 28.0.50; Please document which objects are mutable and which are not References: X-Now-Playing: Oval's _Popp_: "my" Date: Thu, 15 Oct 2020 17:34:41 +0200 In-Reply-To: (Philipp Stephani's message of "Tue, 22 Sep 2020 10:29:22 +0200") Message-ID: <87mu0nv6y6.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Philipp Stephani writes: > The "Mutability" section in the ELisp manual mentions that there are > mutable and immutable objects, but (besides giving a few examples) > doesn't document which objects are actually mutable. At th [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 43557 Cc: 43557@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Philipp Stephani writes: > The "Mutability" section in the ELisp manual mentions that there are > mutable and immutable objects, but (besides giving a few examples) > doesn't document which objects are actually mutable. At the very least, > there should be a list of functions that are guaranteed to return > mutable objects, and a statement about the mutability of function return > values in general. Reading the section, it seems pretty clear to me, and outlines the cases where you can't assume mutability (even if the objects may appear to be mutable). I'm not sure a list of mutable objects is a well-defined request, and there are very few functions that can promise to return a mutable object. (I mean, (list 1 2 immutable-list) is mutable, but can contain elements that aren't.) So I'm not sure whether what you're requesting is feasible. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 31 11:54:56 2020 Received: (at 43557) by debbugs.gnu.org; 31 Oct 2020 15:54:56 +0000 Received: from localhost ([127.0.0.1]:34336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYtDU-0000oa-Fl for submit@debbugs.gnu.org; Sat, 31 Oct 2020 11:54:56 -0400 Received: from mail-ot1-f50.google.com ([209.85.210.50]:44553) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYtDS-0000oN-Ji for 43557@debbugs.gnu.org; Sat, 31 Oct 2020 11:54:54 -0400 Received: by mail-ot1-f50.google.com with SMTP id m26so8438828otk.11 for <43557@debbugs.gnu.org>; Sat, 31 Oct 2020 08:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4dCiN5rXTM5XnYU71SSgUFKZon0PiPcatFUj3ERYuTg=; b=eRYHQjy4w2T0QUU3juWAwuy0aVuVjVgPUfMcNh0Pd4jetqn3JEisFXa6YtEW5Xc2a5 aXOb4HTfQBaD5X6CUUI+n1UZ27tv1+A+Xj8SbISEkOmxlRdGTwdlG4TeNwZHK4Dk3hy/ LTAZgqv4rI9xG74tRW0JKf0Zfg7kbuLzqqDRl8Oik3MSFDU0AyFqkLW6cFik2XkcGcJK gRR8SOUcXp10pCpOBjhe4bvzPyN61feBjfO7vziPfqAodSCi0Wwq/zgDYq9wPPOR11bQ PQunPelurjhNJjxug1+UtxfEdc7qrlj+x1a5DeJ/DQtxdxfS3A5vZ+a36TXws14RMKSo ZY1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4dCiN5rXTM5XnYU71SSgUFKZon0PiPcatFUj3ERYuTg=; b=Oip6BTtOqjGK0vKqC04/aSM8i+Bg9KqBxOPtImNf33YBY3zip2yKsE0g6lkheRhLvX OPaIMplwu7kYFKcxueXPFaQR2YkFC/APLDUvOmTxkGecueO98xpJXZM79xkJztsjiJa3 Rbf9Im8zj0OK5lozjT35XQCW0LEdJU9/URj5LayyxfoMB0ehJyo2Y2YRw2xHzJP/Z0J2 G1L/4OtLud1All/M0h9uqmt5prOVDa0ejaXBw4+lBdBBS9dg6VOIF+ZX3kcJcN541RXt Bhox7jI8uuxhg3bXy8GbVSCBsJDGu0oUCnyMsAM7bxE5TvNXxMGGDhAbvTTAX25l+beb 31Mg== X-Gm-Message-State: AOAM5335omOhecId0PfIvpxrMTt+B5uAyCJ6G/1CbbDPpyYXY0qZCvSC 6NzZwVYJYkTZzhA6pRm2Vtl2UUSjxfYA6o10v+A= X-Google-Smtp-Source: ABdhPJw+i+Lnv0TzCJidh97qpePMLcQTQnD3KtgBWFuvsMeY3u73umHNP6xeqM4IYRza9MS13z+Uclbzc0OZ8mIe5W4= X-Received: by 2002:a9d:6e88:: with SMTP id a8mr5489532otr.174.1604159688818; Sat, 31 Oct 2020 08:54:48 -0700 (PDT) MIME-Version: 1.0 References: <87mu0nv6y6.fsf@gnus.org> In-Reply-To: <87mu0nv6y6.fsf@gnus.org> From: Philipp Stephani Date: Sat, 31 Oct 2020 16:54:37 +0100 Message-ID: Subject: Re: bug#43557: 28.0.50; Please document which objects are mutable and which are not To: Lars Ingebrigtsen Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 43557 Cc: 43557@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Am Do., 15. Okt. 2020 um 17:34 Uhr schrieb Lars Ingebrigtsen : > > Philipp Stephani writes: > > > The "Mutability" section in the ELisp manual mentions that there are > > mutable and immutable objects, but (besides giving a few examples) > > doesn't document which objects are actually mutable. At the very least, > > there should be a list of functions that are guaranteed to return > > mutable objects, and a statement about the mutability of function return > > values in general. > > Reading the section, it seems pretty clear to me, and outlines the cases > where you can't assume mutability (even if the objects may appear to be > mutable). 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. Given that we can't document this for every Lisp function in existence, we need to pick some default, and document that default in the manual. Also, we need to document the cases where the default doesn't apply, either in the manual or in function docstrings. I'm happy to add the necessary documentation, but for that we first need a decision what the default is, and what the exceptions are. > > I'm not sure a list of mutable objects is a well-defined request, and > there are very few functions that can promise to return a mutable > object. (I mean, (list 1 2 immutable-list) is mutable, but can contain > elements that aren't.) Then the docstring of `list' and the ELisp manual should say that. The difference between shallow and deep immutability might not be clear to all readers, so it's important that it's documented as well. > > So I'm not sure whether what you're requesting is feasible. It must be feasible, otherwise programming in ELisp becomes, strictly speaking, impossible. Given code such as (let ((var (some-list-returning-function ...))) ...) it must be possible for programmers to derive whether (setcar var ...) is allowed from some set of rules plus the docstring of the function. This is not some theoretical problem: This bug was triggered by a code review where the author and reviewer disagreed what could be assumed about the mutability of the return value of arbitrary functions, so fixing this bug has very practical consequences. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 03 10:42:13 2021 Received: (at 43557) by debbugs.gnu.org; 3 Jun 2021 14:42:14 +0000 Received: from localhost ([127.0.0.1]:44463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1looXy-0006DW-4P for submit@debbugs.gnu.org; Thu, 03 Jun 2021 10:42:13 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:37037) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1looXs-0006Cy-PC for 43557@debbugs.gnu.org; Thu, 03 Jun 2021 10:42:08 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 08D2C1002C7; Thu, 3 Jun 2021 10:41:59 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 417281001F4; Thu, 3 Jun 2021 10:41:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1622731317; bh=5uEPpLI5CMtRrsgz8NcjYjFsC96TFrzEWCz7t4N4ChQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=VyVfiJiS2Jz0nn7Lekl8pS0usL2yzQEEJSZ2UJjSMf3hKsNI0SmzZaR0Frnu5TJc/ Ce4D9FutRm4uUkN/xXCAvtGG4VVYSWLUnt4OaF30UJ20k84oSVPWlBfQwhSFOkuej0 GaTtJCG4ydGyyE/8FxpbyOk/abXbo++AFy/5ub+EbsATAofvmq6Wi5n3IakZic5Z9B KRifxHT5wMo9+hbOQhNdrEylc9Sl6mewkS2uG6uXDN+buWOLVI9OT8mDReUtXoC/gF XVmqU66c/Q5TcAqRs+Kvwuqztd/VUfe6zRESo1pbbqEDJJf49nOkxqmUr+of7SeerK hvWXZ0yNM2KSQ== Received: from alfajor (69-196-163-239.dsl.teksavvy.com [69.196.163.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 16DEC1202EE; Thu, 3 Jun 2021 10:41:57 -0400 (EDT) From: Stefan Monnier To: Philipp Stephani Subject: Re: bug#43557: 28.0.50; Please document which objects are mutable and which are not Message-ID: References: <87mu0nv6y6.fsf@gnus.org> Date: Thu, 03 Jun 2021 10:41:56 -0400 In-Reply-To: (Philipp Stephani's message of "Sat, 31 Oct 2020 16:54:37 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.053 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 43557 Cc: Lars Ingebrigtsen , 43557@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. 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. > Then the docstring of `list' and the ELisp manual should say that. The > difference between shallow and deep immutability might not be clear to > all readers, so it's important that it's documented as well. This is a pervasive issue, much more pervasive than `list` and that applies to pretty much all programming languages. So I don't think it has its place in the doc of `list`. I hope the box diagrams of the intro to ELisp can be considered a documentation of this phenomenon. > it must be possible for programmers to derive whether (setcar var ...) > is allowed from some set of rules plus the docstring of the function. [ Aha: here's is an example! ] Mutability says whether it is *possible*, rather than whether it's *allowed*. Most (all?) cons cells are mutable, but it is strongly recommended to refrain from mutating most cons cells (because it can/will have unexpected consequences because that same cons cell is also used elsewhere). So what you're asking here is not exactly mutability but something slightly different, which is not very well defined nor documented, indeed. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 04 09:01:53 2021 Received: (at 43557) by debbugs.gnu.org; 4 Jun 2021 13:01:53 +0000 Received: from localhost ([127.0.0.1]:45791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lp9SN-00018Z-TW for submit@debbugs.gnu.org; Fri, 04 Jun 2021 09:01:53 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:33457) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lp9SI-00018H-06 for 43557@debbugs.gnu.org; Fri, 04 Jun 2021 09:01:47 -0400 Received: by mail-wr1-f43.google.com with SMTP id a20so9293918wrc.0 for <43557@debbugs.gnu.org>; Fri, 04 Jun 2021 06:01:41 -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=RQqbYxVe6KlTcO4IqM2hMTqTgtcpTdAtUpkcji9Pao0=; b=cLkvnZi0idVritj9pk9EON5P9vx8HZhPiJJVsg9Mp2oKlbdVvlDMsfCx3upFu388oZ GssRpVMTlkjviWZ47hkP8dJlf8ON6SDYaQagTEW3Uwpm9wTjDVzauy0MHSEZDNx7Rz53 cbvNJyu/AC2ScwGwNeoFzQaptKBnztFQShbvHP15G1+uk7wWxgNV+Zp5YVXzOZHUDAsL rS1f8Hs7vCXkMCKFtAxtDptlYmVGFlGhA70l/OWiVY9tLnv45WiUXr9D3VHA0Ra6opvk mLTWB94FknGaUPNq4HpIE7k1RRCzmlv08wIclUW4cSHLipAwHbIPEyo82U0nQiSPiF5D UCGw== 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=RQqbYxVe6KlTcO4IqM2hMTqTgtcpTdAtUpkcji9Pao0=; b=tFLCKOXznxn9gsfwhVtGTNIJ5WGoQD7l+euh8F2rBR/++ZjiwTa7QdWwKktRxFZqQ7 HQwTgELdaAczI8nMIrqaA2DGX4yKJkubCyV1q9hac5/erfQDAw9zIDLsgzpdSslm2f3r GGsYM1RffiQszKeq6vGP57iZu7YaZm+mIX9cSXu5YbqLIVg4BS4WuVLswxrtUlVSzfYK kW3Kqd37K9nUubVEwZxBDFYJkkO43PUYajkKWluJda3H+KhNfd/ijGoi4hGjK4RfEKHU Zp9fah7avfhJl+BujFmdhhW3K5ODmNaTwFpouWheJl2rnBJjKUBjyKjMILbfoLfaHwfK d3+A== X-Gm-Message-State: AOAM531fEGJicZBbfCd6jIKhKJfTs9hzD6gfsdmNJ+eK3MA29jPEBd2L izQV02w+/7k6O77edoWFzVw= X-Google-Smtp-Source: ABdhPJylAg/GCls5pLju6GRjrENT7jOJR6DwcwuExFGzJ1nmTQUm0htVLBii+QX9WImf01adCkiDVA== X-Received: by 2002:a5d:6b09:: with SMTP id v9mr3814387wrw.297.1622811695900; Fri, 04 Jun 2021 06:01:35 -0700 (PDT) Received: from smtpclient.apple ([46.128.198.100]) by smtp.gmail.com with ESMTPSA id v16sm6074246wrr.6.2021.06.04.06.01.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Jun 2021 06:01:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: bug#43557: 28.0.50; Please document which objects are mutable and which are not From: Philipp In-Reply-To: Date: Fri, 4 Jun 2021 15:01:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78C74FCB-EAEF-4E9F-9C79-3A2178FA60FE@gmail.com> References: <87mu0nv6y6.fsf@gnus.org> To: Stefan Monnier X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 43557 Cc: Lars Ingebrigtsen , 43557@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) > 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. I don't know how concrete a case you want here, but basically I'd like = the manual to describe the semantics of (let ((var FORM)) (setcar var VAL)) 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. >=20 >> Then the docstring of `list' and the ELisp manual should say that. = The >> difference between shallow and deep immutability might not be clear = to >> all readers, so it's important that it's documented as well. >=20 > This is a pervasive issue, much more pervasive than `list` and that > applies to pretty much all programming languages. So I don't think it > has its place in the doc of `list`. >=20 > I hope the box diagrams of the intro to ELisp can be considered > a documentation of this phenomenon. The Lisp manual should still make this distinction explicitly. It can = be derived from the structure of lists, but it's a subtle point that = deserved reiterating. >=20 >> it must be possible for programmers to derive whether (setcar var = ...) >> is allowed from some set of rules plus the docstring of the function. >=20 > [ Aha: here's is an example! ] >=20 > Mutability says whether it is *possible*, rather than whether it's > *allowed*. Most (all?) cons cells are mutable, but it is strongly > recommended to refrain from mutating most cons cells (because it > can/will have unexpected consequences because that same cons cell is > also used elsewhere). >=20 > So what you're asking here is not exactly mutability but something > slightly different, which is not very well defined nor > documented, indeed. I don't think there's a meaningful distinction between "possible" and = "allowed" as far as code authors are concerned, and I don't think the = manual should use such vague terms. Likewise, "strongly recommended" = belongs into a style guide, not a reference manual. In the end, the = ability to write programs boils down to knowing the semantics of the = lexical entities of the programming language in question, and for that = to work the semantics need to be documented. The Info node `Mutability' isn't actually so bad in explaining these = concepts on a conceptual level. It says clearly that mutable and = immutable objects exist, and that attempting to mutate an immutable = object triggers undefined behavior. (I dislike the manual's usage of = the phrase "should not" to mean "undefined behavior", but that's a = different can of worms that we don't need to open here.) I don't want = to introduce new concepts or terminology here. What's missing is really = what this bug is asking for: a procedure to derive the mutability of = objects from the forms that produce them. The `Mutability' node = documents this for some objects, but not all.= From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 04 09:26:13 2021 Received: (at 43557) by debbugs.gnu.org; 4 Jun 2021 13:26:14 +0000 Received: from localhost ([127.0.0.1]:45837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lp9q1-0001jp-Ke for submit@debbugs.gnu.org; Fri, 04 Jun 2021 09:26:13 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:37799) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lp9pz-0001jY-2i for 43557@debbugs.gnu.org; Fri, 04 Jun 2021 09:26:12 -0400 Received: by mail-wr1-f43.google.com with SMTP id i94so4274987wri.4 for <43557@debbugs.gnu.org>; Fri, 04 Jun 2021 06:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vw6HlSPilg9kd88WV21b9IvZg/qaXqLXaUZiCjay82I=; b=F4RtmqMfTPom9RaP/9xCVOjlFOo+BE/dPMnZs+YtgjrIhmgb4uPUxVO4JdEkBi25DD 7g07hS8uZOlrBlQc5U597WbU5I7aooRiKQssa33riDuubx+MwO96h89wv0utNSWgHZco s5JvdWM9ciqK4V2v5y1Z7NaHOOwz5xoNsFjvsO0IB1BDzhdqP/AuLByYIG8aMt5Zlyxt cSF0cydDKZIZXTz4pgMowvD+pImuM1p6QkC9X72wLXhhvOMnwf5o7g4oFmaF9NmY80m4 qJ7l0lae7GlZJPk/Z1BDgv6ftr4VI1ove1UD4S6tR0a4f+gi9ftMM8QBxIrdKRojyf9P p4zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vw6HlSPilg9kd88WV21b9IvZg/qaXqLXaUZiCjay82I=; b=MHqmuhmb6xIvdzKQSs42C/OLAt//+cs5bRy7gpIIyQGSltvpi5MWzhC5UEXNisrkEc k47Q0qdtgP52wdcEefcYhvZBP/CBHHOaYxTmwD9oWxlAKinFi8DyXw/AgIggFHTHFDnW C+4IU6PYmMNMnLznjwS0nf7tWQiMGFWqYxKRE6vTEWk14Q+BYfnQNZUUTPsHF32t1PGI yitv0DuEt600WjgKFb5y6uR85Ay+P5XLb/RuImCjrJb6RlYd4tLnClLbUTul7OP9gFZK JJjseXcJgtFdmJ1+pRYFBHt0t0HNJdFuzyWWg5bCdFWhEbYfNshhWGbn72LzaDC5YRzR 9XGQ== X-Gm-Message-State: AOAM533VDgSDlAG57P23/FL2G5XEjp+npI9NLB3RLiqtfYjiNMijlrHS +w5LciHSx69trKI3ADBnalTku0GgpZc= X-Google-Smtp-Source: ABdhPJzOC2imzCb/spIhDBg06LY2pwpwY+bMfPBnD0U3WC0yLGgXHTxiVvM/C+cp+dB9lnUVD0SZjw== X-Received: by 2002:adf:ee50:: with SMTP id w16mr3902702wro.187.1622813165256; Fri, 04 Jun 2021 06:26:05 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id q5sm6763458wrm.15.2021.06.04.06.26.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Jun 2021 06:26:04 -0700 (PDT) Subject: Re: bug#43557: 28.0.50; Please document which objects are mutable and which are not To: Stefan Monnier , Philipp Stephani References: <87mu0nv6y6.fsf@gnus.org> From: Dmitry Gutov Message-ID: Date: Fri, 4 Jun 2021 16:26:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 43557 Cc: Lars Ingebrigtsen , 43557@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.1 (-) Hi Stefan, On 03.06.2021 17:41, Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > Mutability says whether it is*possible*, rather than whether it's > *allowed*. Most (all?) cons cells are mutable, but it is strongly > recommended to refrain from mutating most cons cells (because it > can/will have unexpected consequences because that same cons cell is > also used elsewhere). See bug#40671 (and the lengthy argument in there) to know how this term in the Emacs manual came to mean something else than it usually means. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 04 09:56:29 2021 Received: (at 43557) by debbugs.gnu.org; 4 Jun 2021 13:56:29 +0000 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 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 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) 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) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: bug#43557: 28.0.50; Please document which objects are mutable and which are not From: Philipp In-Reply-To: <78C74FCB-EAEF-4E9F-9C79-3A2178FA60FE@gmail.com> Date: Fri, 4 Jun 2021 15:56:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F14B065-611C-4ACE-BBD5-50B34512C00B@gmail.com> References: <87mu0nv6y6.fsf@gnus.org> <78C74FCB-EAEF-4E9F-9C79-3A2178FA60FE@gmail.com> To: Stefan Monnier X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 43557 Cc: Lars Ingebrigtsen , 43557@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) > 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?)= From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 05 11:15:18 2021 Received: (at 43557) by debbugs.gnu.org; 5 Jun 2021 15:15:18 +0000 Received: from localhost ([127.0.0.1]:49873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpY17-0006lL-PJ for submit@debbugs.gnu.org; Sat, 05 Jun 2021 11:15:18 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpY13-0006kv-KA for 43557@debbugs.gnu.org; Sat, 05 Jun 2021 11:15:16 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 790AB8091E; Sat, 5 Jun 2021 11:15:07 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EDE1280528; Sat, 5 Jun 2021 11:15:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1622906106; bh=FJV4L9wQ6b0HMalTJ5RAaPelkoX3QFnhXu/V5zO4Wzk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Yzg8AUsdi9BMaHJy3Znk9tYBjizno2PVSoOOYk4tGn+/VdnBcJrMeNk6tKTCKBbUB VI7i/5i7I0loFlTnKhUuSEJvVkljZ3RuJcajU1pzDwUozbPDRNCb0JMGBOoHE0fkov Cgdl2PC8d7zkJW5GMYxTz2jlRxvZXW2MJyL1KZAnhER2gvr3HnWaY83pI4HJq0hY4Q UF4b7xNg2/Lc0KjE6uLxUMLQBAuFdoSIGU1T9yfR2P5Zs9Bnj0SqI6OCNdzkPbFAtD WBxpAtIIbDuIL4R1CoVO0jW9HYJpraK2Sj/0JNKMz0GkisI+S93SbZjQua3vJxshz/ WPEnF9t7fR7kQ== Received: from alfajor (69-196-163-239.dsl.teksavvy.com [69.196.163.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B5AB51204DE; Sat, 5 Jun 2021 11:15:05 -0400 (EDT) From: Stefan Monnier To: Philipp Subject: Re: bug#43557: 28.0.50; Please document which objects are mutable and which are not Message-ID: References: <87mu0nv6y6.fsf@gnus.org> <78C74FCB-EAEF-4E9F-9C79-3A2178FA60FE@gmail.com> <6F14B065-611C-4ACE-BBD5-50B34512C00B@gmail.com> Date: Sat, 05 Jun 2021 11:15:05 -0400 In-Reply-To: <6F14B065-611C-4ACE-BBD5-50B34512C00B@gmail.com> (Philipp's message of "Fri, 4 Jun 2021 15:56:12 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.022 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 43557 Cc: Lars Ingebrigtsen , 43557@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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) I don't think we want to labels this as "undefined" or "invalid" (Emacs and Emacs Lisp tries hard to avoid enforcing abstraction boundaries, and relies instead on softer forms of discipline), but I'd say that using `setcar` above is risky because the user has no guarantee about what it may impact. I think the rule is basically, that you should only ever use `setc[ad]r` on cons cells you yourself created. But indeed the manual fails to document which functions guarantee to return "fresh" new cells, which makes it hard to know which cells "you yourself created". > II. Which of the following implementations of `my-cons' is correct > (i.e. follows the rules of Emacs Lisp as described in the manual)? All of them. > From 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. I think we have (3). Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 05 14:55:15 2021 Received: (at 43557) by debbugs.gnu.org; 5 Jul 2021 18:55:15 +0000 Received: from localhost ([127.0.0.1]:46658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0TkQ-0003KD-NM for submit@debbugs.gnu.org; Mon, 05 Jul 2021 14:55:15 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:40836) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0TkO-0003Jv-N0 for 43557@debbugs.gnu.org; Mon, 05 Jul 2021 14:55:13 -0400 Received: by mail-wr1-f52.google.com with SMTP id l5so6431937wrv.7 for <43557@debbugs.gnu.org>; Mon, 05 Jul 2021 11:55:12 -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=uyx6vHQmXAag8dSu1LufL7WQy69euPzRs6SclYJq5Xg=; b=rGWDsZ16T0dCwUzmRGYYpUpI3lFYXmDk+5ak8tYVEJo5iQCaqxI4zjiKdHHbrmBGBs mLfjs2qsmqdMJkWEKEM+/eE/jXyT5CVrFDlLsVmoFF5cDp66y7ddBaUl6sZiViAbTjrz OjabwOleg7lJyJecGPlv5R953DuczfYkznmZFVtXhXnZBCaNi/8lPltz/Q/Jo1mtnFPo 5+A9YDkwQJSfVXp26n6pCmP6Awb+ZRPtIgSH2Ul913//6RqDDb9+jvoaddQAzFMYg2oi xwJAOZESFqAGBtweGIAHEgPP0gHEDOhSpzkYBfIeUtP20aJCAZekelDgly5dkkBBq67h Qjzg== 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=uyx6vHQmXAag8dSu1LufL7WQy69euPzRs6SclYJq5Xg=; b=Il2BphXkwBbJf2gLVX+yNPYSE0TaqOKgBZLJR8I0MCSxW/itGWHpsDTviNrU/gBFLe FLy1j3lEeIwt0h1cuktEp5o+iG/xCoUmxDRvwIPwCx8Vrc6cZ1my4QLVP/YnwB5h41MR 6fSYd6ksxEEZlaB/PCPFUq4GAcZpu/buIzjUVXJCn+5VcMioSh/tajmBnT9p6UDc2eAc kwVtY85bpFczdOyMijoMvDQQfiRT5JMzh4r0bf/W5fWBpa83Bu4Z5QcQ9XaZMuFlA9rC CDjuhnACMiopF9/1go7VAWLnQUJTn9NlqRL6iXDWBv1Y0ImzMB/EHdRBQdpHuDUHOJN3 KLRw== X-Gm-Message-State: AOAM530mBkmcmsPP5JBTaaAS3Icnb16Typ7gzwdvTrIUzVHNK+iSMEBM ApheQlRckBlECXrkTu+wRTw= X-Google-Smtp-Source: ABdhPJzVN8M85h5XFEPawKeppNBasbiuozu8x4/hEsvnWCF+PEr53n1hZoeMf3XlOuWf+BBmhYfHqw== X-Received: by 2002:a05:6000:1acb:: with SMTP id i11mr16987241wry.120.1625511306693; Mon, 05 Jul 2021 11:55:06 -0700 (PDT) Received: from smtpclient.apple ([46.128.198.100]) by smtp.gmail.com with ESMTPSA id k5sm14377528wmk.11.2021.07.05.11.55.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jul 2021 11:55:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: bug#43557: 28.0.50; Please document which objects are mutable and which are not From: Philipp In-Reply-To: Date: Mon, 5 Jul 2021 20:55:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87mu0nv6y6.fsf@gnus.org> <78C74FCB-EAEF-4E9F-9C79-3A2178FA60FE@gmail.com> <6F14B065-611C-4ACE-BBD5-50B34512C00B@gmail.com> To: Stefan Monnier X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 43557 Cc: Lars Ingebrigtsen , 43557@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) > Am 05.06.2021 um 17:15 schrieb Stefan Monnier = : >=20 >> Assume you have the following (nonsense) function, with unknown = implementation: >>=20 >> (defun my-cons () >> "Return a cons cell consisting of the integers 1 and 2." >> ...) >>=20 >> I. Given only that information and the manual, is the following code = valid >> (i.e. can't trigger undefined behavior in any case)? >>=20 >> (setcar (my-cons) 5) >=20 > I don't think we want to labels this as "undefined" or "invalid" > (Emacs and Emacs Lisp tries hard to avoid enforcing abstraction > boundaries, and relies instead on softer forms of discipline), I'm counting almost 100 occurrences of the words "undefined" or = "unspecified" in the reference manual, so this isn't really new = terminology. It's even used in the manual directly for this purpose: If a program attempts to change objects that should not be changed, the resulting behavior is undefined [...] The remaining weirdness here is saying "objects that should not be = changed" instead of "immutable objects". Most programming languages have some notion of "undefined" or = "unspecified", often to allow optimizations or multiple implementations. = While there are downsides to introducing such behavior, often it's a = reasonable compromise between underspecifying and overspecifying the = language. In this case, the manual already explains in a footnote that the current = behavior is undesirable and Emacs Lisp should move into a direction = where attempting to mutate immutable objects signals an error (thereby = removing the undefined behavior). > but I'd > say that using `setcar` above is risky because the user has no = guarantee > about what it may impact. I think that a word like "risky" has no place in a reference manual. = What does that even mean? What are the risks? Why introduce such vague = and confusing terminology to begin with? How would this help Emacs Lisp = programmers? >=20 > I think the rule is basically, that you should only ever use = `setc[ad]r` > on cons cells you yourself created. What does "should" mean here? What happens if users don't follow this = "recommendation"? How do they identify "cons cells you yourself = created"? Again, I think such terminology brings up more questions than it = answers. > But indeed the manual fails to > document which functions guarantee to return "fresh" new cells, which > makes it hard to know which cells "you yourself created". Then let's document that (while avoiding terms such as "you yourself = created"). >=20 >> II. Which of the following implementations of `my-cons' is correct >> (i.e. follows the rules of Emacs Lisp as described in the manual)? >=20 > All of them. Good. Then let's document that! >=20 >> =46rom what I can see there are four options: >>=20 >> 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. >=20 > I think we have (3). >=20 Can we find a wording that we agree on and put it into the manual?= From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 05 16:35:09 2021 Received: (at 43557) by debbugs.gnu.org; 5 Jul 2021 20:35:09 +0000 Received: from localhost ([127.0.0.1]:46745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0VJ6-0007xc-Pm for submit@debbugs.gnu.org; Mon, 05 Jul 2021 16:35:09 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62030) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0VJ5-0007x2-0X for 43557@debbugs.gnu.org; Mon, 05 Jul 2021 16:35:07 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id CE0F0100104; Mon, 5 Jul 2021 16:35:00 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 60CFE100006; Mon, 5 Jul 2021 16:34:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1625517299; bh=8YOgucCVKRM5A0FJKPysDj68T5+qnr7pTaKJI6j6FC0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=OPknfUjhkHLlzfvReyypg6CHfbqdYAcaZWU9Oq6udjA2h6DGdMs6KHJLJI/Kh1/er +PIuqjeB0vfVhVtauB33yK6wUfGlRD8Cm4fSUUnL+iAAEE3Ml6yj5dWfH06kUxtVPH V7NoXoDuZHigpUTljsZ9GUfi9JbbIEEtmvM5WOIWQAk33FTV6HPfn1GuteIM7nAQEg giABNRjZVjghA8GkAbv6ED3jRmuBI4vzs6+fymDEvVQVW4vjx+uFZmsuDFGXIaJcPq ilmMdr667ru5NeOS0x/sjsnZUnfaon12czHgxvrhhYWep9iE9sYIN6YU4u3vc+JgKw JFT9Zk4AJGwIw== Received: from alfajor (unknown [45.72.205.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3282012033E; Mon, 5 Jul 2021 16:34:59 -0400 (EDT) From: Stefan Monnier To: Philipp Subject: Re: bug#43557: 28.0.50; Please document which objects are mutable and which are not Message-ID: References: <87mu0nv6y6.fsf@gnus.org> <78C74FCB-EAEF-4E9F-9C79-3A2178FA60FE@gmail.com> <6F14B065-611C-4ACE-BBD5-50B34512C00B@gmail.com> Date: Mon, 05 Jul 2021 16:34:58 -0400 In-Reply-To: (Philipp's message of "Mon, 5 Jul 2021 20:55:05 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.062 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 43557 Cc: Lars Ingebrigtsen , 43557@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> but I'd say that using `setcar` above is risky because the user has >> no guarantee about what it may impact. > I think that a word like "risky" has no place in a reference manual. It doesn't have its place in the part that describes technically the effect of the operation. It can have its place in the part that gives recommendations for style and recommended practices. > What does that even mean? What are the risks? That the effect goes further than the author anticipated. > Why introduce such vague and confusing terminology to begin with? In the hope of saving them (and/or others) some serious head scratching, and more generally in the hope to improve the reliability of ELisp code out there. >> I think the rule is basically, that you should only ever use `setc[ad]r` >> on cons cells you yourself created. > What does "should" mean here? It's here a recommendation and a request. > What happens if users don't follow this "recommendation"? Experience teaches us that when a piece of code uses `setcar` on a cons-cell built by some "unrelated" piece of code, there's a high probability that sooner or later the `setcar` will end up modifying more data than intended (because that same cons cell is shared with some other "unrelated" data structure). I.e. you get a bug; one that can take a fair bit of effort to track down. > How do they identify "cons cells you yourself created"? When in doubt, assume that it's not "a cons cells you yourself created". > Again, I think such terminology brings up more questions than it answers. Agreed. Mutation is pretty nasty, indeed. >> But indeed the manual fails to document which functions guarantee to >> return "fresh" new cells, which makes it hard to know which cells >> "you yourself created". > Then let's document that (while avoiding terms such as "you yourself created"). I'd welcome that, yes. > Can we find a wording that we agree on and put it into the manual? I can't think of a reason why not. Stefan