[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Installing cond* in core

From: Dmitry Gutov
Subject: Re: Installing cond* in core
Date: Sun, 28 Jan 2024 15:48:04 +0200
User-agent: Mozilla Thunderbird

On 28/01/2024 15:38, Alan Mackenzie wrote:
Hello, Dmitry.

On Sun, Jan 28, 2024 at 15:02:29 +0200, Dmitry Gutov wrote:
On 28/01/2024 14:38, Alan Mackenzie wrote:
Pretending it didn't happen and failing to discuss it is not healthy for
the project.  Routine bug fixes, and uncontroversial stuff is committed
without discussion, yes.  Otherwise we'd be doing nothing else but silly
discussions on emacs-devel.

The addition of pcase was a boon for the project.

You're missing the point.  pcase has flaws, and even now, 14 years
later, isn't satisfactorally documented.  All you seem to be saying is
that pcase is better than no pcase.  I'd agree with that.

But if pcase were so good, why is Richard writing a better replacement?

It all started with some people not understanding what pcase does and how it works. We're yet to see whether cond* is any better in those areas.

Its uses in particularly important areas, like bytecomp, might have been
a subject for discussion, but we don't really do that when all active
contributors to an area of code agree with the technical decision.

You're being a bit vague there, but when have all active contributors to
any area of code been in agreement?

A lot of times. Or in enough of an agreement for there being no problems to discuss.

And they did agree, otherwise the discussion would have had materialized
at the spot.

That's not the way things happened.  pcase was simply installed in
Emacs, with all its faults, and then proliferated round Emacs.  Where
was the room for discussion?  Discussion is difficult after something
has already been done.

We're doing it all the time by commenting on commits in an email to emacs-devel.

If you're trying to say that pcase is better than nothing, so people use
it, then I'd agree.  But if you're trying to insist it's as good as it
could be,

One does not need to insist on that to disagree with your original statements.

I'd ask you why Richard is spending a lot of time crafting a
better replacement.

Rewriting other people's code that one doesn't understand has a long and varied history in software development. We even have a term for it.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]