GNU logs - #43557, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#43557: 28.0.50; Please document which objects are mutable and which are not
Resent-From: Philipp Stephani <p.stephani2@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 22 Sep 2020 08:30:02 +0000
Resent-Message-ID: <handler.43557.B.16007633749594 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 43557 <at> debbugs.gnu.org
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Tue, 22 Sep 2020 10:29:22 +0200
Message-ID: <wvr4imc6cizh.fsf@HIDDEN>
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@HIDDEN; helo=mail-ej1-x632.google.com
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-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Philipp Stephani <p.stephani2@HIDDEN>
Subject: bug#43557: Acknowledgement (28.0.50; Please document which
 objects are mutable and which are not)
Message-ID: <handler.43557.B.16007633749594.ack <at> debbugs.gnu.org>
References: <wvr4imc6cizh.fsf@HIDDEN>
X-Gnu-PR-Message: ack 43557
X-Gnu-PR-Package: emacs
Reply-To: 43557 <at> debbugs.gnu.org
Date: Tue, 22 Sep 2020 08:30:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 43557 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
43557: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D43557
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#43557: 28.0.50; Please document which objects are mutable and which are not
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 15 Oct 2020 15:35:02 +0000
Resent-Message-ID: <handler.43557.B43557.160277609428160 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Philipp Stephani <p.stephani2@HIDDEN>
Cc: 43557 <at> debbugs.gnu.org
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <wvr4imc6cizh.fsf@HIDDEN>
Date: Thu, 15 Oct 2020 17:34:41 +0200
In-Reply-To: <wvr4imc6cizh.fsf@HIDDEN> (Philipp Stephani's message of "Tue, 
 22 Sep 2020 10:29:22 +0200")
Message-ID: <87mu0nv6y6.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Philipp Stephani <p.stephani2@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#43557: 28.0.50; Please document which objects are mutable and which are not
Resent-From: Philipp Stephani <p.stephani2@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 31 Oct 2020 15:55:02 +0000
Resent-Message-ID: <handler.43557.B43557.16041596963140 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 43557 <at> debbugs.gnu.org
MIME-Version: 1.0
References: <wvr4imc6cizh.fsf@HIDDEN> <87mu0nv6y6.fsf@HIDDEN>
In-Reply-To: <87mu0nv6y6.fsf@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sat, 31 Oct 2020 16:54:37 +0100
Message-ID: <CAArVCkTT+eqZAFvQaDxHHE18XWOrpS+HdRFSzgXHHqMefTEZ4g@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Am Do., 15. Okt. 2020 um 17:34 Uhr schrieb Lars Ingebrigtsen <larsi@HIDDEN>:
>
> Philipp Stephani <p.stephani2@HIDDEN> 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.

Last modified: Sat, 31 Oct 2020 16:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.