Re: Update of pcase docs for the elisp manual

[Eli Zaretskii]

> From: John Wiegley <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Thu, 28 Jan 2016 17:28:30 -0800
> 
> >>>>> Eli Zaretskii <address@hidden> writes:
> 
> >> > AFAIU, your division into logical and literal was different from the
> >> > division between UPatterns and QPatterns. That's why I didn't use those
> >> > terms.
> >> 
> >> Could you explain a bit more how they were different? Such variance was
> >> intended.
> 
> > Sorry, I didn't keep your text after I finished working on this. If you send
> > it to me again, I will try to explain.
> 
> All I meant is, as far as I can tell, UPattern = logical, and QPattern =
> literal, without any variation.

That's not my recollection, but I no longer have the text to prove it.

> >> Ah, so they are syntactical simpler, but not semantically simpler.
> 
> > No, they are also semantically different: they allow more generalized
> > matching rules.
> 
> Different yes, but that's not simpler.

Generalizations are almost always more complex than more specific
cases.

> The rules for understanding what a quoted pattern will do are
> incredibly trivial: it matches per eq with the scrutinee at that
> position.

That's not true.  You have these:

  `(QPAT . ...
  `[QPAT ...

and also

  `(,UPAT

which break your simplistic rule.  (I understand what you want to say,
but saying it in as simplified manner as you did will produce many
errors in actual usage, because it omits crucial details.)

> The rules of understanding what a UPattern will
> do are far more complicated, and can even be extended use pcase-defmacro.

But each UPattern rule, taken alone, is quite simple.

> > I do wonder why these minor nits trigger such a large portion of the
> > comments. They are there to make the text easier to read, so it isn't too
> > dry. If people dislike that style, it's fine with me to delete those parts,
> > but what about "the meat"? Did I succeed to write something that can be
> > studied and learned from?
> 
> Anything, really, is a move forward from what we had before. It's sufficient
> for 25.1 in my opinion.

Thanks.

I will make a few final corrections soon, based on these discussions,
and then I'm done with that part of the manual.