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

[Richard Stallman <rms@gnu.org>]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

Here's how I would write it.  It does not use "literal".
It does use "constant", meaning that the object appears
directly in the expressions and will be used at run time.

A constant does not have to be written in the source.
It could be generated by a macro.

I've assumed that this applies to quoted lists, too, but 
I don't know for sure -- is it so?

I've made several other improvements in the punctuation and usage.
I suggest installing those changes too.

======================================================================
The Emacs Lisp byte compiler may unify identical constant objects,
including strings (which evaluate to themselves), and quoted objects,
including lists, into references to one single object.  This has the
effect that in the byte-compiled code the objects that were unified
are ‘eq’, while when interpreting the same code they are not.

Therefore, your code should never rely on objects that are equal in
contents to be either ‘eq’ or not ‘eq’; it should instead compare them
using functions that compare object contents, such as ‘equal’,
described below.  Similarly, your code should not modify an object that
appears in the code---for instance, it should not put text properties
on strings---since such alteration might affect other objects that
have been unified with it.

======================================================================

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)