RE: [External] : Re: cond* vs pcase

[Drew Adams]

> What bothers me the most about it is that rather [than]
> breaking these problems into simpler operations and
> providing a means of composing them to handle more
> complex situation, the pcase/cond*/loop constructs
> mix them all in to a single form.
> 
> This is defended by saying that it helps move some of
> the complexity from the user to the macro processor.
> But like the current generation of 'generative AI'
> solutions to problems, it seems to hide the complexity
> in a way that subtle errors get hard to discover.  New
> coders end up spending their time copying code fragments
> rather than understanding what is going on.

Indeed.  (And maybe not just new coders.)

But there's room (a "case" to be made) for both:

1. Specific simple, combinable constructs:
   `let', `case', `cond', `if', `when', `or',
   `while', `dolist', `catch',...

2. More generic constructs that combine binding,
   destructuring, and conditional/control:
   `pcase', `cl-loop',...

What there's not a great "case" for is _always_
using #2, just because you can.  You can, but
there can be a cost to your readers.

Occam's razor says _not to multiply things
unnecessarily_.

In this context, does that mean have just one,
generic, complex construct (don't multiply the
number of constructs)?  Or does it mean use the
simplest, clearest construct in each particular
code context?

Does it add unnecessary noise to have a `case'
conditional, in addition to `pcase'?  Or does
it add unnecessary noise to always use `pcase',
including in contexts where it's overkill?

Whether it's `pcase' or `cond*', combining
binding, destructuring, and conditional control
is a mouthful.  It can be powerful, but it can
also be awful.  And even when used correctly,
it can be overkill.

Should we purge Lisp of `let', `cond', `dolist',
and the rest, just because we can do everything
with `pcase' and `cl-loop'?  Silly question, no?

Well that's really the question here.  Let's add
`case' to Elisp (proper).  And let's give it an
optional TEST argument.