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

[Drew Adams]

> > Notice the error msg from (eval ',foo):
> >
> > Debugger entered--Lisp error: (void-function \,)
> >   ,foo
> >   eval(,foo)
> >   (progn (eval ',foo))
> >
> > Nothing in (normal) Lisp syntax shows the use
> > of comma as a function.  ,foo doesn't look
> > like function-call syntax, does it?
> 
> Another side effect of ,X being equivalent to (\, X.).

Yes, that's what I was saying.

> That's the only thing you need to remember.

I think you're making a virtue out of necessity. ;-)

Yes, that's the way comma is implemented inside
backquote in Elisp.  So yes, just remember that
implementation factoid.
 
> > And here's the error from either (read ",")
> > or (eval (read ",")):
> >
> >  End of file during parsing
> >
> > Yes, an error should be reported in each case,
> > but I think it should just say that comma is
> > undefined outside of backquote.
> 
> S-exps are defined recursively.  ",X" is read
> syntax of a valid s-exp,

That it is so is only because Elisp implements it
as that particular read macro.

And the question is about "\,", not ",".

(setq ,X  42) ; => 42
(setq \,X 42) ; => (wrong-type-argument symbolp (\, X))

> Ok, so everything is about that you don't want
> that ,X and (\, X) are equivalent.

You can say that, I suppose.  I'd instead say that
it's about being able to escape a comma inside a
backquote - just like elsewhere, so it's just
treated like a symbol character, even in the case
where it's the only char in the symbol name.

(I'd be interested in what the case is in Common
Lisp, including what a typical implementation is.)

> All your arguments were of the kind "the implications are
> surprising".  But you never answered the core question: what should ,X
> expand to instead that would not have any of these implications?  Else
> all you say is that it's surprising when you lack knowledge.

If you say so.  I haven't said anything about the
implementation: what "," should expand to.  I'd
say that if unescaped its behavior should be to
do what it does now.

(FWIW, I don't think I said that the behavior or
their implications are surprising.  But yes, I
didn't expect "\," to not escape out of the
backquote handling of ",".  I didn't expect comma
to be any different from period or @.)

The question is whether \, and , should have the
same behavior.  Certainly \z and z have the same
behavior.  But character z has no special behavior
inside a backquote.

\@ and @ don't have the same behavior inside a
backquote.  And neither do \. and . -- only \,
and , have the same behavior.  To me, that's just
an implementation/design thing, not something
normal or inevitable.  Not a big deal, not the
end of the world.  I minor unfortunate thing
(gotcha).

> OTOH it seems not easy to find the information ,X == (\, X) somewhere.
> Is there a place where there is said something about the kind of
> expression the reader construct ,X produces?  I didn't find anything in
> a rush.  It should be explained, else this thing indeed can lead to
> surprises, as the one reported here.

I pointed to the comments in the code.  They tell
the story.  But I don't think there's any such
explanation/description in the doc.  Normally we
wouldn't need anything like that -- we'd consider
that to be just implementation/plumbing.  But in
this case it seems that users need to know the
implementation if they're really to understand
the behavior.  But only if they need to use a
symbol named "," normally inside backquote -- a
rare case, surely.

Again, the bug is certainly a tiny corner case.
It's not like users can't use backquote syntax
without knowing this aspect of the implementation.
It's not elegant, but it works pretty well.