Re: cond*

[Adam Porter]

> (symbolp x) is simpler and more natural than the pcase equivalent,
> which I believe would be (and (pred symbolp) x).  People seem to have
> accepted the latter, without criticizing it as unnatural.  

I think that is an apples-to-oranges comparison.  This pcase form:

  (and (pred symbolp) x)

is specifically a pcase form.  It does two things, and--crucially--it 
does them separately and explicitly:

1. It tests the EXP with the predicate `symbolp'.
2. If the test is non-nil, it binds the EXP to `x'.

The list `(pred symbolp)' is obviously not a normal expression, because 
`symbolp' is a predicate function and is unquoted in this list (i.e. 
there is no `symbolp' variable bound).

In contrast, this cond* form:

  (symbolp x)

looks like a normal expression calling the function `symbolp'; and, in a 
sense, it is, because that will happen.  But that same form also binds 
the variable `x' after testing its to-be-bound value with the predicate 
`symbolp'--yet the binding is not explicit and separate, but implicit 
and combined.

Contrast that also with a pcase `guard' form, like in:

  (and x (guard (symbolp x)))

That also does the same thing, but again, the binding and testing are 
separate and explicit.  And it provides the additional benefit of the 
`guard' form being a normal expression, so it could include other parts, 
like:

  (and x (guard (and (symbolp x)
                     (string-prefix-p "foo" (symbol-name x)))))

ISTM that the most potentially confusing aspect of that pcase form is 
that `and' is effectively used to denote binding; and I think that could 
be mitigated by offering an alternative, optional keyword to surround 
bindings, to make them appear more explicit.

> I think they will accept (symbolp x) also.  I think that people will
> get used to this once they start actually using cond*.

By the same token, people could get used to pcase's design once they 
start using it.  But pcase's binding and testing forms are more explicit 
and look less like normal expressions, which makes it potentially less 
confusing to users.

We often bemoan the addition of various libraries to Emacs and ELPA that 
seem to do what existing ones already do, but in slightly different 
ways.  Why not improve pcase to solve these minor shortcomings, instead 
of adding another library that does some similar things, in slightly 
different, incompatible ways, while not even offering as much 
functionality as pcase?  (e.g. as I've mentioned, pcase can destructure 
maps, structs, and EIEIO objects, and is extensible by other 
libraries--it's an incredible tool that I sorely miss when working in 
environments outside of Emacs Lisp.)

--Adam