[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Interpret #r"..." as a raw string
From: |
Matt Armstrong |
Subject: |
Re: [PATCH] Interpret #r"..." as a raw string |
Date: |
Fri, 05 Mar 2021 22:04:54 -0800 |
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.
- Re: [PATCH] Interpret #r"..." as a raw string, (continued)
- Re: [PATCH] Interpret #r"..." as a raw string, Richard Stallman, 2021/03/03
- Re: [PATCH] Interpret #r"..." as a raw string, Daniel Brooks, 2021/03/03
- Re: [PATCH] Interpret #r"..." as a raw string, Eli Zaretskii, 2021/03/03
- Re: [PATCH] Interpret #r"..." as a raw string, Matt Armstrong, 2021/03/03
- Re: [PATCH] Interpret #r"..." as a raw string, Eli Zaretskii, 2021/03/04
- Re: [PATCH] Interpret #r"..." as a raw string, Matt Armstrong, 2021/03/04
- Re: [PATCH] Interpret #r"..." as a raw string, Richard Stallman, 2021/03/05
- Re: [PATCH] Interpret #r"..." as a raw string, Richard Stallman, 2021/03/05
- Re: [PATCH] Interpret #r"..." as a raw string, Eli Zaretskii, 2021/03/05
- Re: [PATCH] Interpret #r"..." as a raw string, Richard Stallman, 2021/03/06
- Re: [PATCH] Interpret #r"..." as a raw string,
Matt Armstrong <=
- Re: [PATCH] Interpret #r"..." as a raw string, Richard Stallman, 2021/03/07
- RE: [External] : Re: [PATCH] Interpret #r"..." as a raw string, Drew Adams, 2021/03/07
- Re: [PATCH] Interpret #r"..." as a raw string, Eli Zaretskii, 2021/03/06
- Re: [PATCH] Interpret #r"..." as a raw string, Daniel Brooks, 2021/03/06
- Re: [PATCH] Interpret #r"..." as a raw string, Eli Zaretskii, 2021/03/06
- Re: [PATCH] Interpret #r"..." as a raw string, Richard Stallman, 2021/03/07
Re: [PATCH] Interpret #r"..." as a raw string, Richard Stallman, 2021/03/01
Re: [PATCH] Interpret #r"..." as a raw string, Alan Mackenzie, 2021/03/01