From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Interpret #r"..." as a raw string Date: Sat, 06 Mar 2021 10:27:06 +0200 Message-ID: <83tupowuud.fsf@gnu.org> References: <20210227.031857.1351840144740816188.conao3@gmail.com> <83pn0mppjd.fsf@gnu.org> <87zgzqz6mu.fsf@db48x.net> <83h7ls67rv.fsf@gnu.org> <83y2f2xc4n.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40501"; mail-complaints-to="usenet@ciao.gmane.io" Cc: db48x@db48x.net, matt@rfc20.org, conao3@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 06 09:28:16 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 1lISIJ-000ARS-GD for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Mar 2021 09:28:15 +0100 Original-Received: from localhost ([::1]:37192 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lISII-0007WJ-IW for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Mar 2021 03:28:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51548) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lISHZ-00075m-LW for emacs-devel@gnu.org; Sat, 06 Mar 2021 03:27:29 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35687) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lISHX-0000Ty-VD; Sat, 06 Mar 2021 03:27:27 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1365 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lISHP-0008Ea-3R; Sat, 06 Mar 2021 03:27:19 -0500 In-Reply-To: (message from Richard Stallman on Sat, 06 Mar 2021 00:13:36 -0500) 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:266059 Archived-At: > From: Richard Stallman > Cc: db48x@db48x.net, matt@rfc20.org, conao3@gmail.com, > monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Sat, 06 Mar 2021 00:13:36 -0500 > > > I understand what you are saying, but still there is a difference > > between > > > (concat foo bar) > > > and > > > (concat foo "what we call a literal string") > > I don't see a deep conceptual difference between them > The secomd uses a constant where the first uses a variable. So it is okay to talk about a "string constant" or a "constant string" instead of "string literal"? And likewise with "literal vectors"? We generally treat these as equivalent terms. Here's an example: When similar constants occur as parts of a program, the Lisp interpreter might save time or space by reusing existing constants or their components. For example, @code{(eq "abc" "abc")} returns @code{t} if the interpreter creates only one instance of the string literal @code{"abc"}, and returns @code{nil} if it creates two instances. Lisp programs should be written so that they work regardless of whether this optimization is in use. As you see, "constants" and "literals" is used here interchangeably. > > 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. Yes, see above (and in general, see the "Mutability" node in the ELisp manual). > This discussion is not about the facts of what happens, if I understand. > It's about the way to conceptualize them. Well, in a way it is about what happens, because almost all instances where we mention "literals" are eventually related to the pitfalls with using those in Lisp code that is byte-compiled. > > 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. I'm still not sure I understand how to correct that. If using "string constant" is what is needed, then it's easy to switch to that terminology throughout. But I'm not yet sure this is the way.