Re: Instead of pcase

[Jim Porter <jporterbugs@gmail.com>]

On 11/15/2023 7:04 PM, Richard Stallman wrote:
> Those of you who are fans of `pcase' may not recognize the cost it
> imposes on the Emacs Lisp language.  You paid that cost already,
> perhaps a few years ago, and perhaps you enjoy each new language
> construct you learn.  Perhaps, for you, the more complexity of
> features to be learned, the better.

I'd like to offer a slightly different perspective here, as someone who 
only fairly recently became comfortable with Lisp (of any variety). I've 
used Emacs for a long time, but I found Lisp completely incomprehensible 
until just a couple of years ago. While getting started with Lisp isn't 
terribly complex, it's still quite a bit to learn, and it took a period 
where I was between jobs before I could dedicate the time I needed to 
get comfortable with writing Lisp.

I encountered a lot of hurdles with Lisp along the way. The first one 
was extremely basic: I needed to get used to the style of indentation 
and develop an intuition for *reading* Lisp code, rather than slowly and 
laboriously translating it into a form I could understand more easily.

The next hurdle was quoting. I still remember that one of my first 
patches to Emacs needed someone else to fix it in a followup because I 
messed up the quoting. The issues of quoting came up repeatedly for me 
as I encountered progressively more complex examples of quoting.

This is where we get to 'pcase'. I'll agree that the upper limit on 
complex quoted forms in 'pcase' is very high. I've used 'pcase-defmacro' 
in one nontrivial case, and I found it very difficult to get right.

*However*, 99% of the 'pcase' instances I've written or encountered are 
pretty simple for me to understand. Once I learned about 'pred' matcher 
and how to destructure via backquote patterns, it was mostly smooth 
sailing for me.

Now, while I'd certainly say that I enjoy learning overall (or else I 
likely wouldn't have learned Lisp in the first place), I don't consider 
the complexity of a feature to be a positive. Instead, I prefer features 
that give me more power or better expressiveness. Often, that 
expressiveness comes at the cost of complexity under the hood (e.g. 
'pcase-defmacro'), but that's not a positive to me in and of itself.

Overall, 'pcase' is one of the parts of Elisp that I appreciate the 
most. Learning the basics of its mini-language took just a bit of 
reading. In addition to the docs, seeing examples helped: the first few 
times were a bit tricky to read, but I could usually understand what was 
happening, even if I couldn't (at the time) write my own 'pcase' code 
that worked. However, once I got the basics down, I quickly saw the 
benefits: I could combine a handful of basic tools to do bigger things, 
meaning I only need to know a small set of facts before I can tackle a 
complex task. This, to me, is the mark of a good language feature: I can 
compose it in ways that *multiply* the power of each (small, easy) bit.

At a higher level, I'd say it's worth considering the audience we want 
to focus on. For veteran (Emacs) Lisp programmers, new additions like 
'pcase' can increase the difficulty of reading new Elisp code: your 
prior mastery of the language isn't any good when you hit that "(pcase". 
However, many programmers today don't know Lisp, of any variety. For 
people like that, learning to contribute to Emacs means learning from 
the very beginning. Having gone through this, most of 'pcase' was very 
easy for me to pick up, and other parts of Elisp were much more 
challenging (it took me a long time to get comfortable with writing 
macros, which is also probably one of the reasons I found 
'pcase-defmacro' to be so tricky).

That said, it's true that every feature we add to Elisp increases the 
overall complexity because now there are more things to learn. However, 
in my opinion, the expressiveness of 'pcase' far outweighs this cost.