Re: Replace trivial pcase occurrences in the Emacs sources

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> 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 can see why someone would feel this way when looking at
a destructuring pcase macro.  But for something like:

    (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))

I have a hard time believing that there are more users who find it less
clear than its cond+eq expansion.

> 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;

Right.

> pcase decides what predicate to use according to the data,

No: it uses `equal` (the implementation may optimize it to something
else, but the documented behavior is that it compares with `equal` for
all patterns of the form 'VAL and for the corresponding accepted
shorthands (i.e. non-quoted strings, keywords and integers)).

> so works with strings, but strangely doesn't work with floats.

Actually it does for a pattern like '4.5
What it doesn't currently is provide the non-quoted shorthand for floats.
Maybe it can be considered strange, but at least it rejects such
a pattern upfront with an error.  Of course, it's trivial to change it
to accept non-quoted floats if we want to do it.

> 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.

When reading pcase code, all they need to know is that comparison is
done with `equal`, which AFAIK is always the most obvious and
natural behavior.

Restrictions like non-quoted floats only impact those rare people which
will *write* a pcase pattern in which they want to put a float.

> By contrast, with cond everything is explicit and self-explanatory.

Every *step* is self-explanatory, but the overall goal is not: as
a reader, I have to scrutinize every condition to see if the overall
goal was indeed to "dispatch based on the value of X".

>> 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.

`pcase` doesn't just change the syntax of cond+eq, like your
BEGIN/END example.  Instead it provides a new abstraction.


        Stefan