emacs-devel
[Top][All Lists]
Advanced

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

Re: combining cond and let, to replace pcase.


From: Dmitry Gutov
Subject: Re: combining cond and let, to replace pcase.
Date: Sun, 19 Nov 2023 16:53:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 19/11/2023 16:49, Eli Zaretskii wrote:
Date: Sun, 19 Nov 2023 15:59:46 +0200
Cc:emacs-devel@gnu.org
From: Dmitry Gutov<dmitry@gutov.dev>

On 19/11/2023 15:08, Eli Zaretskii wrote:
Actually both and none, this is exactly the point I raised in my other
reply - both have exactly the same complexity, and it is totally
subjective and only habit which one you prefer.
It isn't only that.  It is also that the obscure and subtle nature of
regexp strings makes it easy to make mistakes.  Just look at the sheer
number of regexp mistakes uncovered in our code base by Mattias
Engdegård during the last year.  It isn't an accident.
pcase is much better guarded against programmer mistakes because in a
lot of cases typos or misunderstandings will be highlighted by the
byte-compiler (potentially, with flymake directly in the buffer, which I
also recommend everyone to enable).
When we review patches, we don't normally byte-compile the changes,
nor need to run flymake on it.  Usually, it's enough to read the code.
Having to use non-trivial tools (which means apply the changes, which
means use some scratch branch or something similar) is extra hurdle.
It also means patches cannot be easily reviewed if all you have is a
MUA, without a full-blown Emacs development environment.

IOW, it means extra requirements and restrictions, so it's a
disadvantage.  It raises the bar.

When we don't run a patch through CI, or apply it locally, we can just as well miss typos in "simple" code (and have done that on many occasions).

That just puts the burden of testing code code and using flymake on the contributor (both good practices anyway).



reply via email to

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