Re: Replace trivial pcase occurrences in the Emacs sources

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Wed, 24 Oct 2018 16:52:23 -0400
> 
> >     (pcase this-param
> >       ('edit (todo-edit-item--text))
> >       ('header (todo-edit-item--text 'include-header))
> >       ('multiline (todo-edit-item--text 'multiline))
> >       ('add/edit (todo-edit-item--text 'comment-edit))
> >       ('delete (todo-edit-item--text 'comment-delete))
> >       ('diary (todo-edit-item--diary-inclusion))
> >       ('nonmarking (todo-edit-item--diary-inclusion 'nonmarking))
> >       [...]
> 
> Is the below any better?
> 
>     (cond
>       ((eq this-param 'edit) (todo-edit-item--text))
>       ((eq this-param 'header) (todo-edit-item--text 'include-header))
>       ((eq this-param 'multiline) (todo-edit-item--text 'multiline))
>       ((eq this-paran 'add/edit) (todo-edit-item--text 'comment-edit))
>       ((eq this-parom 'delete) (todo-edit-item--text 'comment-delete))
>       ((eq this-param 'diary) (todo-edit-item--diary-inclusion))
>       ((eq this-param 'nonmarking) (todo-edit-item--diary-inclusion 
> 'nonmarking))
>       [...]

Yes (modulo the typos).

> To me, it's more verbose and more complex because you need to double
> check that the same var is tested each time before you can know that it's
> equivalent to a C-style `switch`.

But it isn't equivalent to C-style 'switch': it doesn't compare like C
does, and it doesn't dispatch like C does.  (I find it generally not
useful to think in C concepts when programming in Lisp, because it
might cause confusion and mistakes.)

> IOW, I consider rewriting the `cond` to use `pcase` to be a form of
> "common sub-expression elimination", or reduction of copy&paste.

Unfortunately, it makes the code more subtle and less
self-explanatory.  Not for you and me, perhaps, but for quite a few
people who aren't as familiar with these macros, it seems.

> I think rewriting those pcase uses into cond+eq would be equivalent for
> me to rewriting dolists into while+pop loops

IMO, it isn't equivalent, because dolist doesn't invent new syntax,
not as much as pcase does.

> I prefer pcase to cl-case but I even much more strongly prefer cl-case
> over cond+eq.

The thing is, both cl-case and pcase are subtly different from the
"boring" cond, and from each other.  E.g., cl-case uses eql to
compare, so works with floats, but not with strings; pcase decides
what predicate to use according to the data, so works with strings,
but strangely doesn't work with floats.  Again, perhaps this is not a
problem for you and me, but newcomers might well stumble on these
subtleties, and at the very least will have to consult the docs to
know for sure.

By contrast, with cond everything is explicit and self-explanatory.
The programmer decides which equality to use.  Yes, that does come for
a price, but copy-yanking is cheap and fast, as is "M-/", and also
avoids typos.

> We clearly have very different programming backgrounds: to me the "case
> style" is much nicer and easier to read, closer to what I think in
> my head, whereas the "cond+eq style" is like a "assembly-language"
> version of the same.

This isn't about style, this is about using macro facilities to
significantly change the syntax of a language.

E.g., what do you think about people who use cpp to define macros
BEGIN and END that expand into braces?  One could argue that it is
"closer to what one thinks in their head", or being "higher-level",
and yet such practices are generally discouraged.

> > (Quick: what's the difference between `require and 'require in this
> > case?)
> 
> Same difference as between 'require and `require in normal Elisp code.
> Why is that a problem in pcase and not in the rest of Elisp?

Because people stumble on this and are likely to waste time trying to
understand what kind of magic hides behind this.  Worse, they might
copy this without understanding (as we already see in our sources),
thus proliferating the obfuscation.

Mind you: I'm not against pcase where its power is needed.  It is IMO
needed where using the underlying core facilities would produce
something that is hard to follow and even harder to understand.
Simple comparisons against a collection of fixed values doesn't fit
that bill, IMO.