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, 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: Mon, 20 Apr 2020 12:05:26 +0200 Message-ID: <87k12a4gm1.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> <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> 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="116118"; 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 , Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 20 12:07:33 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 1jQTKv-000U79-6e for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Apr 2020 12:07:33 +0200 Original-Received: from localhost ([::1]:60914 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQTKu-000626-8C for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Apr 2020 06:07:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50674 helo=eggs1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQTIF-0003Bm-0z for emacs-devel@gnu.org; Mon, 20 Apr 2020 06:04:47 -0400 Original-Received: from Debian-exim by eggs1p.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jQTIE-0006if-B9 for emacs-devel@gnu.org; Mon, 20 Apr 2020 06:04:46 -0400 Original-Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]:55235) by eggs1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jQTID-0006aO-QI for emacs-devel@gnu.org; Mon, 20 Apr 2020 06:04:45 -0400 Original-Received: by mail-wm1-x332.google.com with SMTP id h2so10298626wmb.4 for ; Mon, 20 Apr 2020 03:04:44 -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=rmgqwLTAfwndX8pOlvHnSNdZpnpf3mXTb7d9e6KvBe4=; b=X1WJHP9mjmKrpw8F8OmRz2uWS5JDOf7+xSGdO9mcrLsccp4DwtZg3BBpRNw139WIXr pfkP9VoXrry/YbMPmk5pieiCgga5iOjJCy5+rcq4F/eJ5DiHi3g23UJ9jEKkEnrI2y0v SVHpW7yVI24YEhBNc8r7zs6LlANXjbFpOE2IKV8Nz4yiZSov9+rGGzaXHcpISew3AoON ogo8gdqOB6a3auJPxgS8MnbQQ3iqoC8hg+/FphCiCL0n8f1tS6fuyvhTiY5+LYihG0Ra hpcHQpSG7fxCY6i1e+kve3eAGhT4Tz5hl1XbPMfXlyCFgKo9nR4JByaV60vknB2M8YQx Whkw== 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=rmgqwLTAfwndX8pOlvHnSNdZpnpf3mXTb7d9e6KvBe4=; b=IwLTTpT0bKaIdpIGzHKK6Mz6BNW6/C1RbuWea8h6p/CvO9aNenN/bsMvbdyOg3WnXg 405A1xVuzkBmLVhW0cAvzsJ6kX6oh2h9s1hHJ6iQEnaHZRfbXoTP30Dkm5296xZDi0hL ej+hw0KePrprfSWzfv2Or02fldjVQW0prVDaHeExbZw2W0XxrintadrF954HqCDdbjwI +ZoR9MxmXWNEpWd24EKLgZF7t9x8adpVBC5th29m+4MOtWyvxQxeyW7fZfPMLmo29nvz zlvh3QowhCWQJxzQXw/BVmP22aY0HMfRkQsW3TRPYediiM4XoffSJhALJcL2iBUvrgys s9ew== X-Gm-Message-State: AGi0PuaX5ZFxKWKHH8FYn/4KsR/+bXD6dH1jA7Zk14VzavsPZXakKSCO Yl/9hWTBFdH8MlEGGLGar1I= X-Google-Smtp-Source: APiQypK9WkP5KqEKQG9j1Mp5oydYk85JZYyjMyw60FldJXjFD5I8HpDz1u0zmzOJTo9Jza+C7U7Nkw== X-Received: by 2002:a1c:f416:: with SMTP id z22mr16850478wma.32.1587377082990; Mon, 20 Apr 2020 03:04:42 -0700 (PDT) Original-Received: from localhost ([185.112.167.47]) by smtp.gmail.com with ESMTPSA id h2sm571528wro.9.2020.04.20.03.04.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Apr 2020 03:04:42 -0700 (PDT) In-Reply-To: (Paul Eggert's message of "Sun, 19 Apr 2020 16:48:46 -0700, Mon, 20 Apr 2020 02:18:01 +0200, Mon, 20 Apr 2020 02:16:03 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::332; envelope-from=stepnem@gmail.com; helo=mail-wm1-x332.google.com X-detected-operating-system: by eggs1p.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2a00:1450:4864:20::332 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:247373 Archived-At: On Sun, 19 Apr 2020 16:48:46 -0700 Paul Eggert wrote: > On 4/19/20 3:33 PM, =C5=A0t=C4=9Bp=C3=A1n N=C4=9Bmec wrote: > >> 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? > > (let ((str "abc")) > (eq str "abc")) > > This yields t when byte-compiled. OK, that's an interesting example, thanks. I don't think it warrants changing documentation examples like (assoc "simple leaves" leaves) =E2=87=92 ("simple leaves" . oak) to (assoc (copy-sequence "simple leaves") leaves) =E2=87=92 ("simple leaves" . oak) though, because that's not the point that manual section is making: what's important here (unlike the modification examples) is not to make sure the string we're comparing is not the same object as one of the compared list members. We want to use the appropriate predicate, so that no matter the object identity, we get the correct result. So, if you insist that saying that (assq "simple leaves" leaves) returns nil is no good, how about, rather than giving examples that you would never use in real code, we change the examples as follows: (assq "simple leaves" leaves) =E2=87=92 unspecified ; might be nil or non-nil (assoc "simple leaves" leaves) =E2=87=92 ("simple leaves" . oak) Similarly for the others. >> 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. > > Pure lists are not mutable. (Admittedly these are getting rare...) > >> All lists/strings/vectors are mutable in Elisp. > > No, there are exceptions. For example the following makes my Emacs > dump core, even though all it does is modify a string. > > (aset (symbol-name 'cons) 0 ?x) > > It's trying to change the spelling of the name of the 'cons' function, > but that spelling is in memory that the operating system protects on > my platform. This still seems more an issue of terminology: 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. 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 (and I suggest sticking to "undefined consequences" or "safely mutable"; again: I would expect an attempt to modify an immutable data structure to produce an error, not dump core or anything else, and I think that's the general expectation with immutable data structures (and I still think that saying "all Elisp lists/strings/vectors are mutable" is valid in that sense). On Mon, 20 Apr 2020 02:16:03 +0200 Michael Heerdegen wrote: >> 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? > > (eq "" "") =3D> t. You don't even have to compile. Yes, but that's a corner case, similar to there only being one empty list (nil), and I'm not sure it is relevant to the manual sections in discussion here. I'm not even sure it's relevant (for documentation or coding style) at all, i.e., you probably wouldn't recommend using (eq string "") instead of `string-empty-p' or `string=3D'? >> Otherwise, isn't it too hypothetical/theoretical to talk about in the >> manual? > > It is important. This once bit me, and it took a long time until I > found out what was wrong. I had to ask here (AFAIR that's the reason > why an explanation was added to the manual). And it was not code to > provoke that kind of thing. Here I assume you mean something else than the empty string case? --=20 =C5=A0t=C4=9Bp=C3=A1n