RE: [External] : Re: cond* vs pcase

[Drew Adams <drew.adams@oracle.com>]

> > Don't use a jackhammer to drive in a carpet
> > tack, if you have a tack hammer in your tool
> > belt.  (But sure, you can always use the
> > jackhammer if you really want.)
> 
> I think it is more important to be consistent and
> choose one form than many different if possible.

The jackhammer is always "possible".  That doesn't
mean that always using it is the best way to help
human readers of the source code.

> This is a discussion like should I choose setq
> vs setf.

In the abstract, it is.  But the question isn't
abstract.  This is about coding style.  There's
no documented Elisp coding guideline about this, 
so it comes down to personal preference/style.

> Prefering pcase over cl-case, mean you have one
> place to lookup the documentation, one "special
> form" to learn, and so for your users too.

When the "One Way" results in overly complicated
source code it can become an obstacle.

Let a hundred flowers bloom.  You code your way
and I'll code mine. ;-)

I'm the main, maybe the only, reader of my code.

I use `if', `and', `when', etc., following the
convention I related.  I do that _so that I_ can 
more easily  read and understand my own code 
(sometimes years later).  I do that for the same 
reason that I sometimes add a comment with the
reasons behind some bit of code.

It's about human communication.

> It would be much better to have one function
> that let us pass in comparison operator, say
> like this:
> (member element list &optional test-function)

I agree.  It would be good to have that (as in
Common Lisp), and I've said so multiple times.

That doesn't mean we should remove `memq'.
And even if `memq' didn't exist, that wouldn't
be a great argument against adding a `memq'.

> I think it is more of peep-hole optimizing.

Not at all.  It's _not about performance_.
Dunno why people don't get that.  It's about
human communication: code writer/reader.
Just like comments and API doc.

> "Signalling" something to someone by carefully
> crafting use of cl-case vs. pcase sounds like a
> lot of cognitive load on all involved parties

No - the opposite.  And no one's required
to be sensitive to such nuances.

*IF* you know about the convention regarding
when to use `if', `and', `when', `cond',...
*THEN* you can immediately tell (even feel)
what's going on.  This is as natural to
code writers and readers as writing/reading
(car foo) or (let...).

*IF* you're unaware of, or not used to, that
convention, *THEN* you just miss out on that
immediate "intuition"/understanding of what's
going on.  You're not bothered at all.

But yes, you at least need to know what each
of `if', etc. does.  That's really not hard.
It's not hard to learn what `case' does.

> You are basically saying that we should use a
> high-level construct that helps us structure
> our programs according to their implementation
> not for their higher-level feature of singaling
> intention of our code.

I'm absolutely NOT saying that.  I'm saying that
communicating the intention of the code to human
readers is important.