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

[Drew Adams]

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

FWIW, I generally like, and agree with, your take on
this general subject.

I guess the only thing I'd suggest (if it's not already
the case), is that we say explicitly (somewhwere, where
this topic is covered) something like what you said in
your other mail today:

  But there is no distinction between "constant" and
  "variable", and what the code actually contains is
  a string.  A "constant string" is simply a string
  contained in the code.

This too is something not obvious to people not used
to Lisp.

A "constant" object _can_ in general be modified (e.g.
by users/code).  And in some cases (quite common) that's
not a good idea - it's instead a gotcha to beware of.

And the byte-compiler (or even the reader) can sometimes
create a "constant" object, and you might not be aware
of that happening.

(I said "can in general" because Lisp does sometimes
prevent some modification of some constant objects, such
as nil and t.)

The gotcha of inadvertently modifying an object that's,
in effect, "constant" is something to make users aware
of.  How best to do that, I'm not sure.  (That's been
discussed at length in the last year or so.)

Again, I think speaking about "constant" code objects
instead of "literals" is a step forward, (provided we
make clear that in some cases Lisp doesn't prevent you
from modifying such a "constant" object (intentionally
or not).

Your main point, about Lisp programs being data in
memory, not source code in files or buffers or on
paper, is an important one - to be emphasized.