GNU bug report logs -
#61281
“`(a \, b)” equals to “`(a . ,b)”
Previous Next
Full log
View this message in rfc822 format
> > 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.
This bug report was last modified 2 years and 127 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.