GNU bug report logs - #61281
“`(a \, b)” equals to “`(a . ,b)”

Previous Next

Full log

View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Xie Shynur <one.last.kiss <at> outlook.com>, "61281 <at> debbugs.gnu.org" <61281 <at> debbugs.gnu.org>
Subject: bug#61281: “`(a \, b)” equals to “`(a . , b)”
Date: Mon, 06 Feb 2023 06:25:15 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

> > (2) We should (in the recently added function docstrings and the manual)
> > explain that the reader constructs `X, ,X and ,@X are expanded to (or
> > equivalent to) (\` X), (\, X) and (\,@ X) respectively, where the cars
> > are the symbols with the names "`", "," and ",@".
>
> Yes and no, no?
>
> 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).

If the Elisp printer would not sometimes output a syntax like what you
call a "bug case", this would be such an extremely rare appearing corner
case that I really would not mention it explicitly.  Really, this would
make people more wonder about why they need to know that, and distract
from understanding the main points.


> 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.
Relying on the return value of that expression is calling for trouble.
I have the same opinion about this as above.


> 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.

> +;; 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.


Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.