From: Drew Adams <drew.adams@oracle.com>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: Xie Shynur <one.last.kiss@outlook.com>,
"61281@debbugs.gnu.org" <61281@debbugs.gnu.org>
Subject: bug#61281: “`(a \, b)” equals to “`(a . , b)”
Date: Mon, 6 Feb 2023 02:26:47 +0000 [thread overview]
Message-ID: <SJ0PR10MB54884414F3446BD5486B5FE9F3DA9@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87fsbju0of.fsf@web.de>
> > 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.
next prev parent reply other threads:[~2023-02-06 2:26 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-04 23:23 bug#61281: “`(a \, b)” equals to “`(a . , b)” Xie Shynur
2023-02-04 23:34 ` Drew Adams
2023-02-04 23:43 ` Drew Adams
2023-02-05 0:28 ` Michael Heerdegen
2023-02-05 3:30 ` Drew Adams
2023-02-05 4:32 ` Michael Heerdegen
2023-02-05 4:55 ` Michael Heerdegen
2023-02-05 15:53 ` Drew Adams
2023-02-05 23:56 ` Michael Heerdegen
2023-02-06 2:26 ` Drew Adams [this message]
2023-02-06 3:03 ` Michael Heerdegen
2023-02-06 3:49 ` Drew Adams
2023-02-06 10:49 ` Ihor Radchenko
2023-02-06 16:46 ` Drew Adams
2023-02-07 1:07 ` Michael Heerdegen
2023-02-07 1:40 ` Michael Heerdegen
2023-02-07 11:50 ` bug#61281: Double backquote expansion and ", " (was: bug#61281: “`(a \, b)” equals to “`(a . , b)”) Ihor Radchenko
2023-02-07 23:33 ` bug#61281: Double backquote expansion and ", " Michael Heerdegen
2023-02-06 9:40 ` bug#61281: “`(a \, b)” equals to “`(a . , b)” Andreas Schwab
2023-02-06 16:43 ` Drew Adams
2023-02-07 8:56 ` Andreas Schwab
2023-02-07 18:00 ` Drew Adams
2023-02-07 23:44 ` Michael Heerdegen
2023-02-08 3:09 ` Drew Adams
2023-02-08 9:06 ` Andreas Schwab
2023-02-09 1:29 ` Michael Heerdegen
2023-02-09 2:04 ` Drew Adams
2023-02-09 2:15 ` Michael Heerdegen
2023-02-08 9:12 ` Andreas Schwab
2023-02-05 6:32 ` Jim Porter
2023-02-06 0:13 ` Michael Heerdegen
2023-02-06 0:18 ` Michael Heerdegen
2023-02-06 1:14 ` Jim Porter
2023-02-05 15:48 ` Drew Adams
2023-02-05 23:17 ` Michael Heerdegen
2023-02-06 1:49 ` Drew Adams
2023-02-06 4:11 ` Michael Heerdegen
2023-02-06 5:01 ` Drew Adams
2023-02-06 5:22 ` Drew Adams
2023-02-06 5:25 ` Michael Heerdegen
2023-02-06 16:43 ` Drew Adams
2023-02-07 2:00 ` Michael Heerdegen
2023-02-07 18:00 ` Drew Adams
2023-02-07 23:36 ` Michael Heerdegen
2023-02-08 3:09 ` Drew Adams
2023-02-09 1:37 ` Michael Heerdegen
2023-02-09 2:10 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR10MB54884414F3446BD5486B5FE9F3DA9@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=61281@debbugs.gnu.org \
--cc=michael_heerdegen@web.de \
--cc=one.last.kiss@outlook.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).