Re: Code for cond*

[Alan Mackenzie]

Hello, Stefan.

On Wed, Jan 24, 2024 at 01:48:53 -0800, Stefan Kangas wrote:
> 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.

Richard's point, and I agree with it, is that pcase is so far from
perfect that it needs replacing.

> 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'.

It is not a version of pcase.  It is more like what pcase should have
been in the first place.

> 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.

What is its "success"?  It is a failure, being accepted only by some
Emacs hackers.  It is difficult to learn, it may be easy to write, but
is difficult to read, and difficult indeed to debug.

> 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.

I think this is the plan, yes.  We can replace uses of pcase with
equivalent cond* uses, thus improving the readability and
maintainability of our code at a stroke.

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

To solve the problems that pcase has.

> 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.

When pcase was introduced, it was quickly and systematically forced into
(?)every bit of code it would conceivably fit into.  Something similar
could be done for cond*.

> 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.

cond* was designed with the benefit of experience gained from pcase, and
also after extensive open discussion.  pcase had neither of these.  It
is highly likely that cond* will be considerably better than pcase.

It is a bit like programming languages.  The Lisp we use in Emacs now is
quite a bit different from the original Lisp of 1957.  I'm sure we all
agree this is a good thing.

> 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.

That's just a way of ensuring it never comes to anything and just gets
forgotten about.  If that is done, it will be impossible to replace any
of the pcase uses in Emacs with cond*.

A better way of doing this would be to create a feature branch, which
can later be merged into master once its advantages become clear.

-- 
Alan Mackenzie (Nuremberg, Germany).