From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: emacs-27 eebfb72 1/2: Document constant vs mutable objects better, Re: emacs-27 eebfb72 1/2: Document constant vs mutable objects better, Re: emacs-27 eebfb72 1/2: Document constant vs mutable objects better Date: Wed, 22 Apr 2020 10:54:12 -0700 Organization: UCLA Computer Science Department Message-ID: References: <20200418200112.26900.1274@vcs0.savannah.gnu.org> <20200418200114.85C8C20A2B@vcs0.savannah.gnu.org> <87wo6c5vxf.fsf@gmail.com> <54e69de3-f1b9-cbcc-dec1-11f5b1bcd481@cs.ucla.edu> <87o8rn3y2k.fsf@gmail.com> <20200418200112.26900.1274@vcs0.savannah.gnu.org> <20200418200114.85C8C20A2B@vcs0.savannah.gnu.org> <87wo6c5vxf.fsf@gmail.com> <54e69de3-f1b9-cbcc-dec1-11f5b1bcd481@cs.ucla.edu> <87o8rn3y2k.fsf@gmail.com> <20200418200112.26900.1274@vcs0.savannah.gnu.org> <20200418200114.85C8C20A2B@vcs0.savannah.gnu.org> <87wo6c5vxf.fsf@gmail.com> <54e69de3-f1b9-cbcc-dec1-11f5b1bcd481@cs.ucla.edu> <87o8rn3y2k.fsf@gmail.com> <87k12a4gm1.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------29010ED2E86B62989D539859" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="127623"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: emacs-devel@gnu.org To: =?UTF-8?B?xaB0xJtww6FuIE7Em21lYw==?= , Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 22 19:55:45 2020 Return-path: Envelope-to: ged-emacs-devel@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 1jRJb7-000X5b-3a for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Apr 2020 19:55:45 +0200 Original-Received: from localhost ([::1]:55338 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRJb6-0007SQ-57 for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Apr 2020 13:55:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42772) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRJZl-0005kr-V6 for emacs-devel@gnu.org; Wed, 22 Apr 2020 13:54:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jRJZk-0004gY-6i for emacs-devel@gnu.org; Wed, 22 Apr 2020 13:54:21 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:43482) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jRJZj-0004Yf-L5 for emacs-devel@gnu.org; Wed, 22 Apr 2020 13:54:19 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A8DE1160017; Wed, 22 Apr 2020 10:54:15 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id pDRPueZ7qmM7; Wed, 22 Apr 2020 10:54:13 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id EA339160094; Wed, 22 Apr 2020 10:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id D0QhyNstTBgm; Wed, 22 Apr 2020 10:54:12 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id AF164160017; Wed, 22 Apr 2020 10:54:12 -0700 (PDT) In-Reply-To: <87k12a4gm1.fsf@gmail.com> Content-Language: en-US Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/22 13:54:15 X-ACL-Warn: Detected OS = Linux 3.1-3.10 X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:247539 Archived-At: This is a multi-part message in MIME format. --------------29010ED2E86B62989D539859 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 4/20/20 3:05 AM, =C5=A0t=C4=9Bp=C3=A1n N=C4=9Bmec wrote: > how about, rather than giving examples that you would > never use in real code, we change the examples as follows: >=20 > (assq "simple leaves" leaves) > =E2=87=92 unspecified ; might be nil or non-nil > (assoc "simple leaves" leaves) > =E2=87=92 ("simple leaves" . oak) Yes, that's fine. I installed the attached patch, which attempts to addre= ss=20 this, along with other comments by you and Drew. > Similarly for the others. What similar examples are there? As far as I can tell, the other=20 newly-introduced uses of copy-sequence are needed for mutability not uniq= ueness,=20 so they aren't similar. > the examples you give IMO > don't illustrate that some strings or lists are mutable and some are > not; it illustrates that mutating some lists or strings has undefined > consequences. I have a different impression, I think the string that (symbol-name 'lamb= da)=20 returns really is constant. Currently Emacs doesn't behave well if you tr= y to=20 change that string (and Emacs should behave better): but it's a feature n= ot a=20 bug that you can't mess up the Lisp interpreter in such a fundamental way= , and=20 if we make improvements in this area they should not change the fact that= these=20 string values should stay constant. > The point I have been trying to make is that, especially now that > immutable (/persistent/functional) data structures are quite widespread= , > using the mutable/immutable dichotomy in the way you do for Elisp is > confusing But the Elisp documentation doesn't contrast "mutable" with "immutable"; = it=20 contrasts "mutable" with "constant". The documentation avoids the word=20 "immutable" partly to try to avoid the confusion that you mention. There are other languages where "constant" or "const" means "behavior is=20 undefined if you try to change it", not "an exception is thrown if you tr= y to=20 change it"; C and C++ are notable examples. So it's not like the document= ation=20 is inventing terminology out of whole cloth here. If one's expectation is that Emacs will throw an exception if one tries t= o=20 modify a constant then that's unfortunate, because Emacs doesn't do that = for all=20 constants. For now, the manual documents what you can do safely in a Elis= p code;=20 if we improve Emacs so that it reliably signals an error when you try to = modify=20 any constant then we can change the manual to say so. --------------29010ED2E86B62989D539859 Content-Type: text/x-patch; charset=UTF-8; name="0001-Improve-wording-about-constants.patch" Content-Disposition: attachment; filename="0001-Improve-wording-about-constants.patch" Content-Transfer-Encoding: quoted-printable >From 400ff5cd195e81204edd9c69fa1b8bc3cb66b42d Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 22 Apr 2020 10:42:09 -0700 Subject: [PATCH] Improve wording about constants MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit Thanks to =C5=A0t=C4=9Bp=C3=A1n N=C4=9Bmec and Drew Adams for reviews of = recent changes. * doc/lispref/eval.texi (Quoting): Give an example. * doc/lispref/lists.texi (Association Lists): Simplify example code. * doc/lispref/objects.texi (Lisp Data Types) (Constants and Mutability): Clarify wording. --- doc/lispref/eval.texi | 6 ++++++ doc/lispref/lists.texi | 7 +++---- doc/lispref/objects.texi | 21 ++++++++++++++------- 3 files changed, 23 insertions(+), 11 deletions(-) diff --git a/doc/lispref/eval.texi b/doc/lispref/eval.texi index 021604c514..baddce4d9c 100644 --- a/doc/lispref/eval.texi +++ b/doc/lispref/eval.texi @@ -606,6 +606,12 @@ Here are some examples of expressions that use @code= {quote}: @end group @end example =20 + Although the expressions @code{(list '+ 1 2)} and @code{'(+ 1 2)} +both yield lists equal to @code{(+ 1 2)}, the former yields a +freshly-minted mutable list whereas the latter yields a constant list +built from conses that may be shared with other constants. +@xref{Constants and Mutability}. + Other quoting constructs include @code{function} (@pxref{Anonymous Functions}), which causes an anonymous lambda expression written in Lisp to be compiled, and @samp{`} (@pxref{Backquote}), which is used to quote diff --git a/doc/lispref/lists.texi b/doc/lispref/lists.texi index 1125af7bec..ea44e01f48 100644 --- a/doc/lispref/lists.texi +++ b/doc/lispref/lists.texi @@ -1625,10 +1625,9 @@ keys may not be symbols: '(("simple leaves" . oak) ("compound leaves" . horsechestnut))) =20 -;; @r{The @code{copy-sequence} means the keys are not @code{eq}.} -(assq (copy-sequence "simple leaves") leaves) - @result{} nil -(assoc (copy-sequence "simple leaves") leaves) +(assq "simple leaves" leaves) + @result{} @r{Unspecified; might be @code{nil} or non-@code{nil}.} +(assoc "simple leaves" leaves) @result{} ("simple leaves" . oak) @end smallexample @end defun diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index abd258eb53..1eda94ab63 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -46,7 +46,7 @@ you store in it, type and all. (Actually, a small numb= er of Emacs Lisp variables can only take on values of a certain type. @xref{Variables with Restricted Values}.) =20 - Some Lisp objects are @dfn{constant}: their values never change. + Some Lisp objects are @dfn{constant}: their values should never change= . Others are @dfn{mutable}: their values can be changed via destructive operations that involve side effects. =20 @@ -2384,22 +2384,28 @@ that for two strings to be equal, they have the s= ame text properties. @cindex constants @cindex mutable objects =20 - Some Lisp objects are constant: their values never change. + Some Lisp objects are constant: their values should never change +during a single execution of Emacs running well-behaved Lisp code. For example, you can create a new integer by calculating one, but you cannot modify the value of an existing integer. =20 - Other Lisp objects are mutable: their values can be changed + Other Lisp objects are mutable: it is safe to change their values via destructive operations involving side effects. For example, an existing marker can be changed by moving the marker to point to somewhere else. =20 - Although numbers are always constants and markers are always + Although all numbers are constants and all markers are mutable, some types contain both constant and mutable members. These types include conses, vectors, strings, and symbols. For example, the s= tring literal @code{"aaa"} yields a constant string, whereas the function call @code{(make-string 3 ?a)} yields a mutable string that can be changed via later calls to @code{aset}. =20 + A mutable object can become constant if it is passed to the +@code{eval} function, because a program should not modify an object +that is being evaluated. The reverse does not occur: constant objects +should stay constant. + Trying to modify a constant variable signals an error (@pxref{Constant Variables}). A program should not attempt to modify other types of constants because = the @@ -2407,9 +2413,10 @@ resulting behavior is undefined: the Lisp interpre= ter might or might not detect the error, and if it does not detect the error the interpreter can behave unpredictably thereafter. Another way to put this is that although mutable objects are safe to change and constant -symbols reliably reject attempts to change them, other constants are -not safely mutable: if you try to change one your program might -behave as you expect but it might crash or worse. This problem occurs +variables reliably prevent attempts to change them, other constants +are not safely mutable: if a misbehaving program tries to change such a +constant then the constant's value might actually change, or the +program might crash or worse. This problem occurs with types that have both constant and mutable members, and that have mutators like @code{setcar} and @code{aset} that are valid on mutable objects but hazardous on constants. --=20 2.17.1 --------------29010ED2E86B62989D539859--