Re: [PATCH] Interpret #r"..." as a raw string

[Matt Armstrong <matt@rfc20.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Matt Armstrong <matt@rfc20.org>
>> Cc: monnier@iro.umontreal.ca, db48x@db48x.net, conao3@gmail.com,
>>  emacs-devel@gnu.org
>> Date: Wed, 03 Mar 2021 18:47:10 -0800
>> 
>> 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 ‘eq’, 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 ‘eq’ or not ‘eq’, it
     should instead use functions that compare object contents such as
     ‘equal’, 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.