Re: Installing cond* in core

[Dmitry Gutov <dmitry@gutov.dev>]

Hi Alan,

On 28/01/2024 21:14, Alan Mackenzie wrote:

>>>> We're yet to see whether cond* is any better in those areas.
> 
>>> This is true, but it's highly likely cond* will be better.  It's
>>> being designed by an expert designer, and has been through a phase of
>>> open comment and revision.  Also, it takes advantage of the
>>> experience of pcase.
> 
>> A new macro that went through a few rounds of revision with no real
>> consumers yet vs a macro that's been in use for 14 years.
> 
> Yes.  The 14 year old macro has acknowledged faults, the new one doesn't
> as far as anybody yet knows (although it has an area of controversy).

A bunch have already been mentioned. Including (but not limited to) the 
gratuitous incompatibility in syntax where it doesn't have to be 
different when Stefan mentioned lately.

>>> You weren't there at the time.  I was.  I was completely unaware of pcase
>>> happening, and it was a shock being confronted by it for the first time.
> 
>> If you weren't aware, then you weren't working on that area of code, right?
> 
> I was not.  pcase was first committed on 2010-08-04 in commit
> d02c9bcd096c44b4e3d5e2834c75967b56cdecdd.  There was no prior discussion
> about it on emacs-devel.

So, you wanted it to have been discussed with... simply someone? I'm 
guessing it must have been, in public or in private.

And if you were looking for the reasoning behind it, there are a few 
paragraphs about it in Stefan's paper: 
https://dl.acm.org/doi/pdf/10.1145/3386324 (Section 8.3, page 37).

>>>>> 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.
> 
>>> You cannot disagree with my original statement made last night.  As I
>>> said, you weren't there at the time.
> 
>> I don't have to insist it's as good as it could be to object to throwing
>> it out.
> 
> Your wish has been fulfilled.  Eli's and Stefan K's decision from last
> night is 100% in favour of those who want the use of pcase to carry on
> unchanged.  cond* has been consigned to a few niche uses before it is
> even up and running.

The proof is in the pudding. Personally, I *would* have put it in ELPA 
after some sufficiently broad announcement that there is this new 
powerful syntax endorsed by the maintainers of Emacs (or some of them), 
that the package authors could use. And see how well that turns out. The 
alternative-syntaxes packages (like f/s/dash) have been fairly popular 
among the package author community. But for some reason people who don't 
like pcase here, don't seem to like ELPA either.

For my part, I'm concerned that cond* turns out to be a weaker, 
arbitrarily incompatible version of pcase, and only practice can prove 
otherwise. Committing to changing a whole swaths of code to it risks 
fixing in stone any current deficiencies. Not to mention that taking 
over the code that Stefan still maintains to an extent would not be very 
friendly.

>> Not the lack of talent, mind you, or potential, but insufficient
>> understanding and skill with that tool (destructuring pattern
>> matching--which is not unique to Elisp and has carryover from a number
>> of other programming languages) is what motivated this whole argument.
> 
> Unlike most of Emacs Lisp, pcase is peculiar in that only some hackers
> can get to grips with it.  You seems to be one of them, I am certainly
> not, and neither is Richard.  The decision recently taken will mean you
> need not trouble yourself with cond*, and people like me will continue to
> be hindered and slowed down by pcase code for the foreseeable future.

Just to be clear, I like pcase not because I am particularly clever, but 
because my brain can only fit a limited number of things at a time 
(ideas, processes, or words on the screen), and a succinct syntax that 
uses principles I can recognize allows me to understand such programs 
quicker, cutting out the boilerplate.

>> And I'm really skeptical that when cond* goes through all the additional
>> revisions and gets as powerful as pcase, that it won't raise all the
>> similar questions.
> 
> Possibly, but not inevitably.  Its syntax is kinder on the eye than
> pcase's.  Maybe people would object to it because it requires the use of
> multicharacter keywords and is bulkier, and so on.  I can't tell at this
> stage.

If being slightly more verbose is going to be its only problem, I'd say 
we're in a good place.