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

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

>> We currently don't have a special "fail" pattern which simply never
>> matches.  Of course, you can make one up (e.g. (guard nil)).
> (or) would also do it, but raises (error "Please avoid it")  (BTW
> (or _) raises that error, too).  Why are those (error "Please avoid it")
> calls useful?

IIRC handling them well (i.e. generate efficient code) required more
effort than I was willing to invest, or something like that, and IIRC
they should only show up in unusual cases, so I made them signal errors,
to try and see when/where those cases show up.
So far I never bumped into them and haven't received any bug report
about them either.  We should probably remove them, tho, because those
corner cases may be annoying to avoid when doing metaprogramming.

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

OK, changed.

> because
>   SELFQUOTING	is a shorthand for 'SELFQUOTING.
> sounds like a tautology.

As a teacher I was taught that redundancy in explanations is good ;-)

>> As explained the use of `eq' is supposed to be a pure optimization with
>> no semantics effect.

> I see.  Then I guess it would make sense to merge these two lines in the
> ` doc?

>   STRING                matches if the object is ‘equal’ to STRING.
>   ATOM                  matches if the object is ‘eq’ to ATOM.

Yes, thank you, done.


        Stefan