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

From: Michael Heerdegen <[email-masked]>
Date: Mon, 06 Feb 2023 06:25:15 +0100

Drew Adams <[email-masked]> 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.