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

[Matt Armstrong]

Richard Stallman <rms@gnu.org> 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 ‘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.

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.