From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Interpret #r"..." as a raw string Date: Fri, 05 Mar 2021 22:04:54 -0800 Message-ID: <87v9a4n7g9.fsf@mdeb> References: <20210227.031857.1351840144740816188.conao3@gmail.com> <83pn0mppjd.fsf@gnu.org> <87zgzqz6mu.fsf@db48x.net> <83h7ls67rv.fsf@gnu.org> <83y2f2xc4n.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22870"; mail-complaints-to="usenet@ciao.gmane.io" Cc: db48x@db48x.net, conao3@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org, Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 06 07:05:56 2021 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 1lIQ4a-0005ra-62 for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Mar 2021 07:05:56 +0100 Original-Received: from localhost ([::1]:45136 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIQ4Z-0006SI-6J for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Mar 2021 01:05:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35818) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIQ3o-0005wb-EX for emacs-devel@gnu.org; Sat, 06 Mar 2021 01:05:08 -0500 Original-Received: from relay2-d.mail.gandi.net ([217.70.183.194]:41055) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIQ3l-00064e-Cq; Sat, 06 Mar 2021 01:05:08 -0500 X-Originating-IP: 24.113.169.116 Original-Received: from mdeb (24-113-169-116.wavecable.com [24.113.169.116]) (Authenticated sender: matt@rfc20.org) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 3B82B40006; Sat, 6 Mar 2021 06:04:57 +0000 (UTC) In-Reply-To: Received-SPF: pass client-ip=217.70.183.194; envelope-from=matt@rfc20.org; helo=relay2-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:266055 Archived-At: Richard Stallman writes: > > And in fact, the difference is not only visual, because the > > byte-compiler is allowed to treat such "literal" strings specially in > > some situations. > > I am not entirely sure what that refers to; I am sort-of guessing. > The thing it is treating specially is a string in the expression being > compiled, if I understand what you mean. > > This discussion is not about the facts of what happens, if I > understand. It's about the way to conceptualize them. > > > Another reason is that many (most?) readers understand "literal > > string" in the sense of the above example, so it is a convenient way > > of making sure the reader understands what is being discussed. > > Yes and no. Readers who know other languages will get an immediate > understanding from "literal string". But that understanding is not > exactly the right understanding. So we ought to correct it to get to > the right understanding. The place Eli was referring to, I believe, is this from (info "(elisp)Equality Predicates"): The Emacs Lisp byte compiler may collapse identical literal objects, such as literal strings, into references to the same object, with the effect that the byte-compiled code will compare such objects as =E2=80=98eq=E2=80=99, while the interpreted version of= the same code will not. Therefore, your code should never rely on objects with the same literal contents being either =E2=80=98eq=E2=80=99 or no= t =E2=80=98eq=E2=80=99, it should instead use functions that compare object contents such as =E2=80=98equal=E2=80=99, described below. Similarly, your code should= not modify literal objects (e.g., put text properties on literal strings), since doing that might affect other literal objects of the same contents, if the byte compiler collapses them. How might this paragraph be rephrased in a way that doesn't use the term "literal", yet remains clear. I think I follow this discussion, but I'm not at the point where I could rewrite that paragraph myself. I have too much ingrained understanding of static programming languages and their literals and not enough exposure to the way these concepts are described for Lisp languages.