Re: Code for cond*

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> I'm going to do some more testing and then install cond*.

I'm sorry for paying so little attention to this.  I was not aware that
there was a plan to install `cond*', or I would have spoken up sooner.

While I don't want to claim that `pcase' is perfect and impossible to
improve upon, I don't find `cond*' convincing.

Whatever else is true, a new macro will increase the complexity of ELisp
and make the task of maintaining Emacs harder.  If the downsides to
having two ways of doing the same thing are to be worth it, it needs to
be demonstrated that the new one offers substantial improvements.

Here, it is not clear that `cond*' offers much in the way of either
simplifications, or powerful new ways to express ideas and solve
problems.  What I see instead is a mere _version_ of `pcase'.

Now, the `pcase' macro has been with us for 14 years already, and we
have had plenty of time to learn its ins and outs.  It's heavily used in
many parts of Emacs, and many of us rely on it as a matter of routine.
Its success is not surprising, given that this style of pattern matching
is increasingly common in other programming languages.

Does the "install `cond*'" proposal come with a plan to replace `pcase'
everywhere?  That sounds like a bad idea: it would lead to code churn,
unhappy maintainers of subsystems that use `pcase', and, of course, bugs
in both the code being changed and in `cond*' itself.

If it does _not_ come with such a plan, it's slightly better.  But then
that begs the question: why add it?

To avoid having to bikeshed about whether or not to use `pcase' or
`cond*' every single time, I think we will have to capitulate the
argument, as we sometimes do, and say that the choice is a matter of
personal style.  Which, if we are being really honest, it really is.

We will end up with `pcase' for those that happen to prefer that, and
`cond*' for those that happen to prefer that.  For me, as a maintainer,
I now have to know not one, but two relatively complex macros.  While I
realize that ELisp has been largely designed in an ad-hoc way,
consciously introducing such needless proliferation does not strike me
as a particularly good way to design a programming system.

In summary, I recommend installing `cond*' as a new package on GNU ELPA.
This is a good way of exploring an alternative version of an existing
macro.