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

[Drew Adams]

> > I see a difference between escaped comma and
> > escaped comma before @.  The above "are expanded
> > to" doesn't cover this, I think.  For example:
> > [...]
> > `(a \, foo) ; ==> (a 4 5)   - bad, the bug case
> 
> It's a logical consequence (although not an obvious one, but also not
> totally unobvious) of the fact that this expression is equivalent to
> `(a . ,foo).

Again, I think you're describing the implementation,
not why it _should_ behave this way.

IF
we assume (whether or not this bug will be fixed),
as I thought we agreed (?), that it makes more sense
for bare "\," within backquote, just as outside it,
and just as for UNbare escaped comma (e.g. "\,xyz"),
whether inside or outside backquote, to escape/undo
the backquote-meaning of ","

THEN
the sexp `(a \, foo) should just return (a \, foo),
a list of three symbols.

> > The \,@ cases and the \,foo case "work" because
> > \, immediately followed by any escaped char or
> > unescaped whitespace etc. works.  It's only \,
> > followed by unescaped whitespace etc. that
> > doesn't work.
> 
> `(a \,@ foo) would correspond to `(a . ,@foo), which 
> would be illegal as backquote expression.

Whether "illegal" or not, in Elisp it already
works as I would expect, and as I showed:

3. `(a \,@ foo) ; ==> (a \,@ foo) - good

Elisp correctly escapes the comma, to be a normal
symbol constituent, and the symbol name ",@" is
used.  Nothing in the backquote sexp calls for
any evaluation; the result is the same list of
3 symbols as the input to `.

> Relying on the return value of that expression 
> is calling for trouble.

How so?  On what basis do you think it's "illegal"?

> I have the same opinion about this as above.

Which is that it runs counter to what you say
the Elisp implementation gives?  But clearly the
Elisp implementation doesn't agree.

The only bug, IMO, is that an escaped isolated
comma is not actually escaped from the backquote
interpretation/behavior of comma.  There's no bug
for an escaped comma that's immediately followed
by other symbol chars (including @).
 
> > Agreed, but I don't think just describing those
> > expansions that way is sufficient.  For one
> > thing, what's X?  Whether certain chars follow
> > the comma immediately makes a difference.
> 
> The author is allowed to add more details about
> how the reader parses that character of course.

Author of the code?  The original comment?  My
mail?  I don't have a suggestion for the comment
improvement.  Unless it's to say what I've said
in this thread, perhaps showing some of the cases.
Or maybe just refer to this bug thread in the
comments.  And perhaps adding a FIXME to confirm
that there's a bug - if, that is, the Deciders
agree.

> > +;; When the Lisp reader sees `X it generates (\` X).
> > +;; When it sees ,X it generates (\, X).  For ,@X 
> > +;; it generates (\,@ X).
> >
> > I don't think that's sufficient - see above.
> > ,X and ,@X aren't handled the same, and it
> > matters what X is.  X is not necessarily a new
> > sexp.
> 
> For the file header this is enough IMO, it only clarifies 
> what the backquote macro gets to see and needs to handle.

The behavior depends on what X is allowed to be.
Is it something that parses (is read) as a separate
sexp?  Is it any sequence of chars?  Any sequence
of symbol chars?

I guess at this point we understand each other and
can just agree to disagree.  And I guess we agree
that it's unlikely that the bug will be fixed.  And
if it were fixed there may be some code that depends
on the bugged behavior (very unlikely, IMO).  And
(more likely), the fix might introduce new bugs, as
this seems tricky.