Re: Replace trivial pcase occurrences in the Emacs sources

[Garreau\, Alexandre]

On 2018-10-25 at 17:47, Eli Zaretskii wrote:
>> From: Stefan Monnier <address@hidden>
>> Date: Wed, 24 Oct 2018 16:52:23 -0400
>
>> 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.

Is this about the fact you need “break” in C to get the same behavior?
Then a lot of programmers “as a good style” put it at the end of each
case, because they don’t even know they can do otherwise, and what does
that actually mean.

> (I find it generally not useful to think in C concepts when
> programming in Lisp, because it might cause confusion and mistakes.)

Maybe it’s more a matter of programming habits than of C concepts.  And
factorizing conditionals seems to be a pretty common thing.

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

People also have a habit of defining macros to factorize code so that to
match their thinking and expression of what they want to achieve: that’s
why I and many others end writing new personal conditional such as
case*.  But these not being standard, they’re way less explicit and
self-explanatory, as each re-definition will potentially loose unaware
people, be incompatible with others, and will be more of a burden for
readers of programs using them.  While encouraging mainline and standard
forms for common subexpressions elimination make people use them instead
of making up their own, and therefore make their software easier to
read.

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

Because each one of these have real advantages as well as disadvantages,
and, more importantly, neither of them is more clearly expressible as a
composition of the other, compared to the other way around (eg. you can
translate BEGIN END to { } or the other way around, none of both is more
simple, natural or straightforward than the other).

While this is clearly the case for pcase, cl-case, and finally cond, as
each one of them can be more easily defined on top of, respectively,
case, cond, and if.  So the former are higher-level while the later are
lower-level.  Level is more a question of abstraction rather than
(subjective) thinking.

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

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

cl-case does, imho.  I’d appreciate, as well as others, I think, an
official version with equal (case-equal, or casequal maybe?), or even a
more general version (with as second argument the test function to use):
either named case* (I recall having seen somewhere the convention of
appending a “*” for the general version (that asked for a test function)
of a comparision form, do anyone know where it might come from? as I’m
now unable to find it again), or maybe using a :test and :test-not
keywords.

Maybe even a version not quoting its keylists?