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

[Eli Zaretskii <eliz@gnu.org>]

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