RE: The poor state of documentation of pcase like things.

[Drew Adams <drew.adams@oracle.com>]

> Well, I'd say that pcase is kinda awkward because you can't tell by
> skimming whether it's complex or not

100% agreement.  That's really the point, for me.

* `pcase' shouts: "This might be complicated.  Better look closely."

* `cond' and `cl-case' and `if' ... shout: "Nothing fancy here.
  We're only testing literals"

>              (pcase status-symbol ...)
> 
> The only way you'll know whether `status-symbol' is really a symbol, and
> all the cases are really symbols, is by reading the entire thing.  The
> 44th case could have been (_ foo bar zot), for instance.
> 
>              (case status-symbol ...)
> 
> and you'd know that this was a simple `eql' thing going on here.
> 
> I kinda liked pcase at first, but the more I see of the pcase language,

Good one.  That's really it.  When you have a very general
construct it can begin to be its own _language_.  This is the
case for UNIX `find', for instance, and for Common Lisp `loop'.

That's not to say that using such a language can't be useful.
It's only to say that I use it when it is most useful.  If I
don't need it then I tend not to use it.

> the more sceptical I get.  I'm beginning to wonder whether the whole
> thing is a misfeature that should be replaced with several separate
> operators.

That's an interesting question.  Maybe you have something in mind?
Could be an interesting thread, even if it ultimately went nowhere.
Certainly, something like `pcase' provides a good deal of food for
thought, which can also mean room for improvement.