On Mon, Dec 4, 2023, 6:58 AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 03 Dec 2023 22:08:21 -0500
>
>   > This is not true.  There is no magic at all in the use of this reader
>   > feature which is totally lost after reading.  It is absolutely
>   > impossible to detect its use afterwards.
>
> As a factual matter about dotted pairs in pcase patterns, that is
> correct.
>
> However, we have repeatedly seen that experienced Lispers, who would
> have no trouble understanding those constructs in a backquote meant to
> actually construct a structure of conses, don't know what to make of
> them on encountering them in pcase patterns.
>
> That's another factual matter about dotted pairs in pcase patterns.
> It is more a psychological matter than a computational matter, but
> that doesn't invalidate the observation.
>
> It is part of the impact of complexity of pcase.

Some people are saying that everything is clear because the Lisp
reader does this and that.  But when humans read code, they don't
normally run the Lisp reader in their head, they use other techniques
to read and grasp what the code does.  If there's a need to ask what
does the Lisp reader do with some syntax, that is already an obstacle
to understanding the code, even though eventually one can understand
it, whether by thinking what the reader does or by actually running
the reader and/or macro-expansion.

I'm saying it makes no sense to me to lay the blame at the feet of the pcase syntax.

Elisp will happily evaluate the expression 
(if . ( t . (nil . (t . nil))))

Would you, or anyone, say that reflects some flaw in the design of the "if" form?

Lynn