From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?utf-8?B?xaB0xJtww6FuIE7Em21lYw==?= Newsgroups: gmane.emacs.devel Subject: Re: emacs-27 eebfb72 1/2: Document constant vs mutable objects better Date: Mon, 20 Apr 2020 00:33:39 +0200 Message-ID: <87o8rn3y2k.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="32653"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 20 00:33:59 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 1jQIVj-0008PZ-6s for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Apr 2020 00:33:59 +0200 Original-Received: from localhost ([::1]:48320 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQIVi-00014J-9K for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Apr 2020 18:33:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37790 helo=eggs1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQIUn-0000V0-Ge for emacs-devel@gnu.org; Sun, 19 Apr 2020 18:33:02 -0400 Original-Received: from Debian-exim by eggs1p.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jQIUl-0005OX-BM for emacs-devel@gnu.org; Sun, 19 Apr 2020 18:32:59 -0400 Original-Received: from mail-wm1-x341.google.com ([2a00:1450:4864:20::341]:38195) by eggs1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jQIUj-0005Lt-Qb for emacs-devel@gnu.org; Sun, 19 Apr 2020 18:32:57 -0400 Original-Received: by mail-wm1-x341.google.com with SMTP id g12so9221169wmh.3 for ; Sun, 19 Apr 2020 15:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=9blkqSz7Al+FfthJGIokV1BexgftN7/6WwLrSO6NC1Q=; b=h7ymzeDrfpfEoipWOv3dvPgHS8r5iTxdyZqb1AAScIQiEg79n4VNX1sfw8CBlCoyww Aiq2kfkHC7LDPVn10gTcOYiN5YuKaJMwfdF8XCpbA9moWepa8eRbhMBkzNyJ1yOOl61B 946FBaV61Qgk62UEzcQA3Uqa4ASnhujinBNCK48QZdjCJoZfsc1tlFtJVSFTgQ58FbrU tLAnsMs0/VrX5dh8BGh5J4ppLc2w/pYlxjwwqK09KyE9vT7K1Ma5lSDdCHQXG14FZBZo OvdodSaXqhP6mi088C1lVMt1vgrw21Hi3ACt+bTngaN8bOd03sBPsUmFuKxrAQfCC0o1 dQqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-transfer-encoding; bh=9blkqSz7Al+FfthJGIokV1BexgftN7/6WwLrSO6NC1Q=; b=ZqrctkKqLAn48f5KqNPdAQ0a1LVz5IL0GB6o6wYFvEh657DlW9NkqeNxI9IQMW+ZDB q8UYAKQ+ZX3RzeEInP7ME2oPir+RBXxv4jzO2JVwUx2RMJZUilSMsEobDULNQROP3Gtk zcbNGkrUAw3zZ/Dpky5Xs6OjwSoTIZB1COXddzEZRH7E1HckbuJKW/CoFg87V0EgQGCO KaBrsLv+dGfBgdtYJyyd5EF0qqulUhjjsG/1W2W8o0OzqZqhKbCikbzdxPVAqG/5KeZ7 n21bAzYIx/vAAyRul+3dnSSm3uAfL/ASayYo2HRPtsY2oPH5K8ZIZdMlCz6wBqRI4Gd3 e6qg== X-Gm-Message-State: AGi0PuaXVINlKeHtzRbe+ki2s9MnqgJ6uvibQu8CxL6B4MamLxbyuyc6 HE6VWg8JegtCNe4q3CFbl3s= X-Google-Smtp-Source: APiQypLfPkq0ppX8f7fj2m2izMp4MkZuvz6/jpSj5u8qZog0LSp3UZ9VHJ7oyG6adxzjmLCgZsfSPw== X-Received: by 2002:a1c:3dd6:: with SMTP id k205mr14518367wma.138.1587335577041; Sun, 19 Apr 2020 15:32:57 -0700 (PDT) Original-Received: from localhost ([185.112.167.47]) by smtp.gmail.com with ESMTPSA id d133sm18398997wmc.27.2020.04.19.15.32.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2020 15:32:56 -0700 (PDT) In-Reply-To: <54e69de3-f1b9-cbcc-dec1-11f5b1bcd481@cs.ucla.edu> (Paul Eggert's message of "Sun, 19 Apr 2020 13:37:54 -0700") Received-SPF: pass client-ip=2a00:1450:4864:20::341; envelope-from=stepnem@gmail.com; helo=mail-wm1-x341.google.com X-detected-operating-system: by eggs1p.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::341 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:247330 Archived-At: On Sun, 19 Apr 2020 13:37:54 -0700 Paul Eggert wrote: > Unless otherwise specified, the patch simply adopts your other > suggestions. Thank you, and sorry for aggravating your pain. Regarding comparing two equal floats, strings or lists by `eq', you warn about its undefinedness ("might not return nil") repeatedly, but can you give an actual example where (eq 1.2 1.2) or (eq "string" "string") returns non-nil in Elisp? Otherwise, isn't it too hypothetical/theoretical to talk about in the manual? I guess it is imaginable that a compiler might do that, but so are other things that Elisp could do but doesn't. >> IOW, "mutable" and "safely >> mutable"/"mutating it is a good idea" should be distinguished. > > The attached patch makes that distinction in a new section "Constants > and mutability" that I hope clarifies some of the issues here. While > writing this, I noticed that for Elisp we needn't separate the three > notions (not-mutable-and-this-is-checked, not-safe-to-mutate, > safely-mutable) everywhere; all we need to do is describe those > notions in one spot, and everywhere else we can just use the term > "mutable" for safely-mutable and the term "constant" for everything > else. I think there is no disagreement about the issues involved, but about the terms used to describe them. I still think that formulations like "the other arguments (all but the last) should be mutable lists" are unfortunate, because all Elisp lists are mutable. IOW, "mutable" and "immutable" seem better suited for data structure classification than Elisp best practices recommendations. All lists/strings/vectors are mutable in Elisp. The manual had better describe under what circumstances one should not mutate them, and I don't think calling the same data structure once "mutable" and once not will help rather than confuse or mystify. > diff --git a/doc/lispref/eval.texi b/doc/lispref/eval.texi > index 46cfab164b..deb288943a 100644 > --- a/doc/lispref/eval.texi > +++ b/doc/lispref/eval.texi > @@ -158,6 +158,12 @@ contents unchanged. > @end group > @end example >=20=20 > + A self-evaluating form yields a constant, and you should not attempt > +to modify the constant's contents via @code{setcar}, @code{aset} or > +similar primitives. The Lisp interpreter might unify the constants ^^^^^^^^^^ In the Elisp manual, "primitive" is defined as "A function which is callable from Lisp but is actually written in C", but I think we want to say that one shouldn't try to modify constants, period; no matter the particular means used. > +yielded by your program's self-evaluating forms, so that these > +constants might share structure. @xref{Constants and Mutability}. > + > @@ -1306,10 +1306,10 @@ same way in Lisp input. >=20=20 > A vector, like a string or a number, is considered a constant for > evaluation: the result of evaluating it is the same vector. This does > -not evaluate or even examine the elements of the vector. Vectors > -written with square brackets are constants and should not be modified > -via @code{aset} or other destructive operations. > -@xref{Self-Evaluating Forms}. > +not evaluate or even examine the elements of the vector. > +@xref{Self-Evaluating Forms}. Vectors written with square brackets > +are constants and should not be modified via @code{aset} or other > +destructive operations. @xref{Constants and Mutability}. This is a good formulation IMO: no "(im)mutable" needed. Such and such are (considered) constant/literal, and should not be modified/modifying them leads to undefined consequences. Thanks, =C5=A0t=C4=9Bp=C3=A1n