bug#20784: 25.0.50; pcase documentation on t and nil

[Stefan Monnier <monnier@iro.umontreal.ca>]

> (pcase 5.0
>   (5 5)
>   (5.0 5.0))  => 5.0

Hmm... indeed, I used "numbers" (and `numberp') in pcase, where I really
meant "integers".  That's a bug.  The above code should (IMO) signal an
error indicating that floats aren't accepted as patterns.  The intention
is that SELFQUOTING should always be matched with an `equal' semantics
(`eq' is used on integers and keywords as a plain optimization which
should not affect the semantics).
E.g. using `eq' on strings makes string patterns simply unusable.

> The case of t is especially non-obvious; it's neither treated as

Yes, it was a mistake to accept t to mean the same as `_'.
Not sure if it's too late to fix it, but t should not be accepted as
a special pattern.  We could handle it like nil (i.e. pretend it's
a normal variable which then signals an error when we try to let-bind
it) or emit a warning.

> never", but raises an error when used  ("applies never" could make
> sense when the code is generated by a macro).

We currently don't have a special "fail" pattern which simply never
matches.  Of course, you can make one up (e.g. (guard nil)).  I think
making nil such a pattern would probably lead to more errors/confusion
than anything, since it's extremely rare to need such a pattern.

> I think I would consider to trivialize the semantic, merging the
> SELFQUOTING and 'VAL case.

We could drop the SELFQUOTING case, but I added it because it lets you
reduce the clutter of quoting, which tends to be fairly high in
pcase patterns.

> semantic of 'VAL as it is now, as it is perfectly clear.  To substitute
> the SELFQUOTING thing, we could allow something like ATOM - which can be
> any atomic expression that is not a symbol that can be bound - and make
> it simply an abbreviation for 'ATOM.

That's pretty much what SELFQUOTING is.  IF you think renaming it to
ATOM would help, then we could do that.

> (FWIW, unifying `ATOM and 'ATOM would IMHO also be worth it;

They should behave identically, yes.

> currently 'ATOM is compared always with
> `equal', whereby `ATOM is compared with `equal' for strings and `eq'
> else.

As explained the use of `eq' is supposed to be a pure optimization with
no semantics effect.  The fact that we accept floats and compare them
with `eq' is a plain bug.


        Stefan