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: Fri, 05 Mar 2021 10:01:28 +0200 Message-ID: <83y2f2xc4n.fsf@gnu.org> References: <20210227.031857.1351840144740816188.conao3@gmail.com> <83pn0mppjd.fsf@gnu.org> <87zgzqz6mu.fsf@db48x.net> <83h7ls67rv.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1154"; 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 Fri Mar 05 09:02:49 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 1lI5Q9-000067-6q for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Mar 2021 09:02:49 +0100 Original-Received: from localhost ([::1]:56576 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lI5Q8-0006ll-9E for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Mar 2021 03:02:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43080) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lI5PH-00068x-Ki for emacs-devel@gnu.org; Fri, 05 Mar 2021 03:01:55 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53320) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lI5PF-0004s7-EA; Fri, 05 Mar 2021 03:01:53 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2391 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lI5P6-00031N-1P; Fri, 05 Mar 2021 03:01:45 -0500 In-Reply-To: (message from Richard Stallman on Fri, 05 Mar 2021 00:39:27 -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:266015 Archived-At: > From: Richard Stallman > Cc: eliz@gnu.org, db48x@db48x.net, conao3@gmail.com, > monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Fri, 05 Mar 2021 00:39:27 -0500 > > In Lisp, a program is a data structure. It does not contain string > literals -- it contains strings. Thus, various sections of the manual > can talk about what happens if you use a string in a certain > expression, but they don't need to talk about the printed representation > of that expression. 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") Even if 'bar's value is the same string as the one that appears literally in the second example, there's at least a visual difference. And in fact, the difference is not only visual, because the byte-compiler is allowed to treat such "literal" strings specially in some situations. This is one reason why the ELisp manual mentions literal strings: it needs to describe those special situations and the pitfalls they bring with 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. Why is it harmful to use this terminology in conjunction with Lisp, even though its semantics in Lisp is somewhat different?