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

[Drew Adams]

> > Yes, but see above.  I think \, should be
> > read as the symbol whose print name is ",".
> 
> That's the case.

Inside a backquote, an escaped comma's handled
as if it were unescaped.  That's the bug.
 
> > To me, `(a \, b) should be treated like
> > (a foo b): a list of 3 symbols - no evaluation.
> 
> No evaluation by backquote, you mean?

I mean that \, is not (should not be) the same
as comma whether inside or outside a backquote.

It is (should be) only an UNescaped comma that
(1) when inside backquote introduces evaluation
of what follows it and (2) raises an error when
not inside a backquote.

> Yes, you need to say `(a ,'\, b).

When I said "no evaluation" I meant that \,
shouldn't cause evaluation inside backquote. 
I wasn't talking about evaluating the symbol
\, itself - I'm not interested in doing that.

I'm talking about the special interpretation
of \, here, i.e., its being handled just like
an UNescaped comma, instead of just like any
other symbol (e.g. foo).

> Is this really different in other Lisps 
> (isn't `,' a reader macro in Common Lisp)?

It may be, dunno, but I'd bet that Common Lisp
treats unescaped comma differently from escaped
comma.

I meant that reading \, should be like reading
foo, whether inside backquote or not.  The only
thing that should introduce evaluation within
a backquote is an UNescaped comma.

\, is not ,

Dunno about the reader macro question.  (But
I'm guessing that the overall difference here
is how the CL reader works, yes.)

> I don't decide about this, but when we changed
> the semantics of `,' like you suggest, we will
> probably break a lot of code for no real gain
> (I think the semantics in Elisp clear and easy
> to understand), so this sounds like a very bad
> idea to me.

I'm not saying the bug should be fixed.  I have
the same concern you express.  Not that I really
think that "a lot of code" will break (I don't),
but that (1) some code might depend on this
behavior and so break, and (more importantly)
(2) it's likely that the new code will introduce
other (new) backquote bugs.  There be dragons.

What I expect is that the bug will be closed as
"wont-fix".  This should nevertheless be seen
as a (minor) bug.  It should be noted somewhere
(at least called out in code comments).

Whether it's important enough to merit mention
in the Elisp manual, I don't know.  Normally
it's not, but someone actually stumbling on this
would need to check the code to discover it and
would need to recognize that it's a bug by design.

File backquote.el says clearly at the outset:

;; When the Lisp reader sees `(...), it generates
;;   (\` (...)).
;;
;; When it sees ,... inside such a backquote form,
;;   it generates (\, ...).
;;
;; For ,@... it generates (\,@ ...).

It's _good_ that it says this.  That's a pretty
clear description of the implementation / design.

(Except that the use of (...) and ... in what the
reader sees doesn't make clear what those stand
for.  Backquote applies to unparenthesized sexps
also.)

It could also usefully say that this doesn't
provide exactly the usual Lisp backquote behavior.
It could call out what we're talking about:
_escaped_ comma is (wrongly) treated as unescaped
comma inside a backquote.  That's the design,
AFAICT, and that's not the traditional behavior
(IIRC).