From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#40671: [DOC] modify literal objects Date: Sun, 10 May 2020 18:47:25 -0700 (PDT) Message-ID: References: <012e8bc3-df4b-3884-4e54-5fe7ef4248cb@cs.ucla.edu> <37a54ac2-da80-ca35-9c01-38c8e12a4b5f@yandex.ru> <9375aaeb-2a9a-b307-c793-0d99328201ea@yandex.ru> <7fe0574a-62ae-94fb-2e55-1a69de6ce828@cs.ucla.edu> <91857438-f44a-90f4-dfe2-a32224ba3994@yandex.ru> <880dc34b-46a9-0149-3c6e-0a951a70125d@cs.ucla.edu> <9c46b93e-a855-0be0-7ab0-50cb8c5cd74d@yandex.ru> <48e90f87-1519-9101-d54b-4bfd81a0c936@yandex.ru> <252d6368-ddea-2f41-b53f-cd927ebc3d1d@cs.ucla.edu> <43d93102-d361-f64b-971b-909418b89fca@yandex.ru> <2ca64f28-1255-4135-6e45-0f0e12b9e72d@cs.ucla.edu> <0c7570cb-bf52-a617-bf54-27a47c54e04a@cs.ucla.edu> <04298f7d-f2c0-5186-57d3-522e3d886166@cs.ucla.edu> <88af48c6-bc39-6ab0-59ec-7d537f2d375d@yandex.ru> <41d69e2e-561f-743a-e1f0-282b2e22b66c@cs.ucla.edu> <87mu6ftk6o.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="55884"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ke.vigouroux@laposte.net, Dmitry Gutov , 40671@debbugs.gnu.org, Richard Stallman , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= To: Michael Heerdegen , Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 11 04:26:37 2020 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 1jXy9M-000EQa-Vz for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 May 2020 04:26:37 +0200 Original-Received: from localhost ([::1]:42202 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXy9M-0000to-2A for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 May 2020 22:26:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34674) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXy8y-0000Mb-Us for bug-gnu-emacs@gnu.org; Sun, 10 May 2020 22:26:13 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39269) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jXy8y-0007He-Le for bug-gnu-emacs@gnu.org; Sun, 10 May 2020 22:26:12 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jXxZ0-00035H-0O for bug-gnu-emacs@gnu.org; Sun, 10 May 2020 21:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 01:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40671 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158916168211749 (code B ref 40671); Mon, 11 May 2020 01:49:01 +0000 Original-Received: (at 40671) by debbugs.gnu.org; 11 May 2020 01:48:02 +0000 Original-Received: from localhost ([127.0.0.1]:50789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXxY1-00033M-To for submit@debbugs.gnu.org; Sun, 10 May 2020 21:48:02 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:55968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXxXz-00032t-52 for 40671@debbugs.gnu.org; Sun, 10 May 2020 21:48:00 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04B1lhIL032545; Mon, 11 May 2020 01:47:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=ctzBK2muA5ixTLBZIXKeOdzVuKW2wxiQKsGgNQIdpV8=; b=nHONRWMziSLKoUVkh1i5WxGALRIwbExIDg8v1j1T+zV07cqamxM1F/PWQVio6heA/daT 4I4P5kRzuXNrKj0rkmTrwNAUP0EgV1a+CAnmW/m4yj40XhEUzdw/N/TmOF1drQ/UK1Vz ewWzFbLLRYR6Jz69Z3MtBgI8eSb12W/UGRbSlBAJmIdijIEeiq/7CrIdYq/7Wav20T8a nClVYZbdMiAldKGiyhLTkbcFnx/5AlmglC+ESO6szJ3qTRJXWd1gNjoTT9zig/oI/cIt nboODr1AqtJmFMQdHy3w9IvT+xpofeNmqa50X21EkNxrJTIQrkodGGMTvu+cIy6ib2I/ NQ== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 30x3mbjd6r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 11 May 2020 01:47:42 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04B1iN4V120400; Mon, 11 May 2020 01:47:42 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 30xbgc6raa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 May 2020 01:47:41 +0000 Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 04B1lQGZ026647; Mon, 11 May 2020 01:47:28 GMT In-Reply-To: <87mu6ftk6o.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9617 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=999 spamscore=0 suspectscore=18 phishscore=0 bulkscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005110012 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9617 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 impostorscore=0 mlxscore=0 suspectscore=18 bulkscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 lowpriorityscore=0 spamscore=0 adultscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005110012 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:180044 Archived-At: > Symbols are constant AFAICT, their bindings > are not (variables are not constant). Their bindings as variables are not constant, except for keyword symbols, nil, and t (are there any others?). But are symbols otherwise constant, besides their values? Depends what you mean by "symbol", perhaps. Certainly you can change not only `symbol-value' but also `symbol-function' and `symbol-plist'. I don't see symbols as very constant. [Personally, as I suggested, I don't think the text about this gotcha should get down in the weeds about mutable/immutable anything. I think it should stay general, not try to catalog specific problems (e.g. strings, conses, whatever). It should show and explain a very simple example of what can happen with a quoted list, and then leave it at that. Maybe it should mention, as you said a while back, that there are the reader, interpreter, and byte compiler, when saying something about the problem in general. But I already said all this, and I said I was done here...] BTW, in Common Lisp you can even do nasty things like modify the `symbol-name' of a symbol. For that, CLTL2 says:=20 "It is an extremely bad idea to modify a string being used as the print name of a symbol. Such a modification may tremendously confuse the function `read' and the package system." That's the _kind_ of somewhat vague gotcha description I think we should have. Enough to let users know they don't want to do it. > > + A mutable object stops being mutable if it is part of an > expression > > +that is evaluated. For example: >=20 > FWIW, I would feel better about the word "mutable" if you would > introduce the term like "safely mutable", and then say that we call it > just "mutable" in the following sections because this is shorter. Drew > mentioned his dislike for the term "safe" AFAIR=20 I don't recall saying that, but I may have. Not sure what's meant here. I objected to using "dangerous", as if the gotcha was generally hazardous to life. > but I think "my Emacs > won't crash if I follow this" vs. "it can crash" describes some kind of > safety. Ignore if this comment is irrelevant because this is already > done or treated otherwise. To me, the problem for users is not so much that Emacs can crash as it is that they may lose data. Or more likely (and worth mentioning, I think, as a motivator) that they might have a heck of a time trying to figure out why their code doesn't seem to behave as they expect. Seeing a quoted list in source code can make you think new list structure is created each time that code is run. Code "initializing" part of some list structure to a quoted list might give you the impression that that's what happens each time (e.g. each time a function that seems to do that gets called), but the same cons from a first evaluation (or reading) of that quoted list might remain in use for each invocation of the function. And if you at some point modify that cons then you might not get your apparent "initialization" to that quoted list each time the function's invoked. > > + When the same value appears multiple times ^^^^^ ^^^^^^^ > > +in a program, the Lisp interpreter might save > > +time or space by reusing existing values or ^^^^^^ > > +their components. >=20 > I think we call "values" what evaluation of expressions yields, so > values don't appear in a program (to be read). I don't know the > backgrounds and when this can happen. Is it always the interpreter > that does this mapping? I think that text wasn't too bad, but I see your point. And it's especially not good to use "value" in the two different senses, as (1) something you see ("appears") in a source program and (2) a runtime value that results from reading, byte-compiling, or interpreting that source code. Maybe "object" or "Lisp object" instead of "value", for #2? (Note: I didn't read the full text. I'm just reacting to what was cited in your mail. Sorry.)