bug#61281: “`(a \, b)” equals to “`(a . , b)”

[Drew Adams]

(Michael, I started to reply to your message
by explaining what I meant by escaping and
unescaping, but I think you do know what I
have in mind.)

I guess an argument can be made that there's
no bug here.  I don't think that's right, but
I can see an argument for it.

Outside backquote (and outside a string etc.)
you need to escape a comma: "\,".  Otherwise,
an error is raised.  Escaping it means it's
read as part of a symbol name.

Comma is special in this way.  And an escaped
comma read on its own produces the symbol
named ",".

It's the need to escape a comma normally that
makes me think that the same kind of escaping
should remove the special behavior that comma
has inside backquote, and just have it be
treated by the reader as a symbol there.

For characters other than comma, which don't
raise an error without escaping generally, a
backslash (aside from particular contexts)
generally is a no-op: \X is the same as X for
a character X.

Because of that, you could make an argument
that that's what should happen for comma
inside backquote: a backslash to escape it
should have no effect.  That's clearly what
_is_ happening, in any case.

I don't think that's the most logical behavior,
because comma in Lisp otherwise behaves so
differently if escaped or not (just read as
a symbol-constituent char when escaped).

And not the best behavior, because it makes it
impossible to use a symbol named "," within a
backquote, without having it get the special
backquote comma behavior.  You can't remove
the special behavior that backquote gives it.

Normally, the special behavior of any char can
be removed, to include it in a symbol name,
including to use it alone as a symbol name.

In particular, note that @ doesn't have the
same problem that comma has.  You can remove
its special meaning there, to make it just be
read as a symbol, by backslash-escaping it:

(setq \@  '(3 4))
(setq foo '(4 5))

`(a ,\@ foo) ; ==> (a (3 4) foo)
`(a ,@  foo) ; ==> (a 4 5)

If @ behaved like comma here, then both of
those backquote sexps would result in (a 4 5).

Likewise period - behaves as I would expect:
backslash-escaping it removes its special
backquote behavior.

(setq \. '(1 2))

`(a .  ,foo) ; ==> (a 4 5)
`(a \. ,foo) ; ==> (a \. (4 5))

If period behaved as comma does then both of
those backquote sexps would result in (a 4 5).

Of course, there's no crying _need_ to use
symbols named ".", "@" and "," as variables,
functions, etc. inside a backquote.  But why
not, and why not be consistent among all such
special chars?