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: Thu, 04 Mar 2021 08:55:12 -0800 Message-ID: References: <834khrjaf4.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="35036"; mail-complaints-to="usenet@ciao.gmane.io" Cc: db48x@db48x.net, emacs-devel@gnu.org, conao3@gmail.com, rms@gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 04 17:58:20 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 1lHrIq-0008yX-KN for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Mar 2021 17:58:20 +0100 Original-Received: from localhost ([::1]:59866 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHrIp-00089q-2Y for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Mar 2021 11:58:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39958) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHrG3-0006XG-5F for emacs-devel@gnu.org; Thu, 04 Mar 2021 11:55:27 -0500 Original-Received: from relay6-d.mail.gandi.net ([217.70.183.198]:43869) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHrFz-0007mb-1L; Thu, 04 Mar 2021 11:55:26 -0500 X-Originating-IP: 24.113.169.116 Original-Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com [24.113.169.116]) (Authenticated sender: matt@rfc20.org) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 4B031C0003; Thu, 4 Mar 2021 16:55:15 +0000 (UTC) In-Reply-To: <834khrjaf4.fsf@gnu.org> Received-SPF: pass client-ip=217.70.183.198; envelope-from=matt@rfc20.org; helo=relay6-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_H2=-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:265972 Archived-At: Eli Zaretskii writes: >> From: Matt Armstrong >> Cc: monnier@iro.umontreal.ca, db48x@db48x.net, conao3@gmail.com, >> emacs-devel@gnu.org >> Date: Wed, 03 Mar 2021 18:47:10 -0800 >>=20 >> I have noticed that most Lisp reference material does not use the word >> "literal" to describe source code elements. Which raises the question: >> how does Lisp documentation typically talk about these things? > > What is a "source code element"? Like you I'm trying to figure out why, in Richard's words, the concept of "literal" does not fit Lisp very well. One sense defition of "literal" is "Of, in, or expressed by a letter or the letters of the alphabet." and this is the sense I believe most people mean in programming contexts. With my current understanding, I think this meaning applies to Lisp as well as it does in any other language. I don't take this to imply that the particular word "literal" is necessarily the preferred way to describe the concept in Lisp. Let's go back to Richard's original text: > The concept of "literal" does not fit Lisp very well. It describe > the situation with other languages, where expressions are not > objects, only syntax. In those languages, you don't put a string > into your program, only a "literal" which represents a string value. > > In Lisp, what you put in the program _is_ a string. What you write > in the textual code is not a "literal", it is the textual > representation of the string to put in the program. My observation is that most descriptions of source code syntax for Lisp languages do not use the term "literal". Instead, they describe the "read syntax" of each object. Similar for printing, with language such as "`prin1' produces output suitable for input to `read'" and phrases like "printed representation of ...". When I first learned Lisp I was left wondering why these long phrases were repeated over and over thruought the documentation. Then I had the thought: By "printed representation of a string" and "read syntax of a string" they are just describing "string literals" :-) In Richard's text above he uses language that I consider confusing: "In Lisp, what you put in the program _is_ a string." Why confusing? Because if "put in program" is talking about source code, the statement isn't true. What you put in the program is a quoted sequence of characters, perhaps in US-ASCII, perhaps in UTF-8, perhaps some other encoding, depending on the encoding of the entire file. This character sequence is parsed by the reader according to certain syntactic rules. The running program represents the equivalent string object entirely differently: as an array of characters, perhaps multi-byte, perhaps not, always without the outermost quotes, etc. Most notably, the program can then very conveniently mutate the string, whereas Lisp provides no primitives to conveniently mutate the original source code. So, given that there is a difference between a string in source code and a string at run time, a concice phrase that designates the "printed representation of objects of type X as written in source code" feels useful. I do agree that elisp.info could be improve in some uses of the term "literal." For example, in this description of `eq': 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. For one, I have not found a place in the reference where the terms "literal object" and "literal string" are defined. A new programmer could be easily confused. It may be useful to describe the general issue being described to here in a more prominent location, since it its relevance to `eq' is just one of possibly many issues. E.g. mutating any quoted object can cause the object to be different each time a function is called, even if the "literal object" remains `eq' across calls.