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

[Drew Adams]

>    (pcase foo
>      ('bar (do-some-bar-stuff))
>      ('baz (do-some-baz-fluff)))
> 
> is not more awful or wonderful than:
> 
>    (cl-case foo
>      (bar (do-some-bar-stuff))
>      (baz (do-some-baz-fluff)))

Exactly.  The difference is tiny when the
two are, uh, doing the same thing.

When `pcase' is used only to do what
`cl-case' is designed for, it doesn't
proclaim immediately to readers that
that's all it's doing.
___

However, our doc actually claims that a
`pcase' version of a similar example is
_superior_ to `cl-case' (not just-as-good).

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68029

 "This shows that you do need to use a `code'
  variable (you named it `val' though), and
  that the pcase version is indeed better."

(The `pcase' example actually uses _more_
variables than the `cl-case' example, in
spite of the doc claiming that it's better
because it uses fewer.)

If our doc and a maintainer can mistakenly
think `cl-case' is required to bind more
vars in such an example, then imagine how
mixed up a reader might be.

The point about using `cl-case' (or `cond'
or whatever else) in particular cases (vs
rather, using `pcase' in other cases) is
that doing so conveys the info that we're
talking about a simple or a not-so-simple
case.

If you use `pcase' for something for which
`cl-case' easily suffices, that can be less
clear than reserving `pcase' for heavier
lifting (when it's really needed).

Using them both, each for what it can offer,
can elucidate just what work is involved.

> And neither of them is worse than what they expand to:
>    (cond ((eql foo 'bar)
>           (do-some-bar-stuff))
>          ((eql foo 'baz)
>           (do-some-baz-fluff)))
> 
> Nor is this:
>    (pcase foo
>      (1 'ONE)
>      (2 'TWO)
>      ((cl-type function) (funcall foo))
>      (_ 'SOMETHING-ELSE))
> 
> any worse than what it expands to:
>    (cond ((eql foo 1)
>           'ONE)
>          ((eql foo 2)
>           'TWO)
>          ((cl-typep foo 'function)
>           (funcall foo))
>          (t
>           'SOMETHING-ELSE))

Of course.  Did someone argue that `pcase'
doesn't compile or macroexpand to efficient
code?

It's a style/messaging question.  Using
`pcase' for what `cl-case' can't do easily
and clearly can then say, "This here ain't
a straightforward `cl-case' thing."

You don't have to adopt such a convention.
But you can.  Then when your readers see
`pcase' they'll pay attention, looking for
what _particularly called for_ using it.

>    (pcase foo
>      (1 'ONE)
>      (2 'TWO)
>      ((cl-type function) (funcall foo))
>      (`(,fn . ,arg) (funcall fn arg))
>      (_ 'SOMETHING-ELSE))
> 
> I cannot fathom how this optionally available
> "power" is a problem which should consign PCASE
> to only exceptional cases

No one suggested that.  Saying that it can
help to use `cl-case' when it perfectly fits
the bill is not the same as saying that one
should always use `cl-case'.

The argument is against always using `pcase';
it's not for always using `cl-case' (or `cond'
or...).

Use each for what it can do well/better.  And
yes, it's only about coding style; it's not
about performance differences.  (Maybe ask
yourself why you'd think the question is about
performance?)
  
> any more than Lisp's
> power should consign it to only a few libraries, leaving the rest to be
> implemented in lower-level languages; or any more than Emacs's power
> should consign it to only a few use cases, leaving the the rest to be
> implemented in utilities to be piped together in a shell.

That's precisely the point.  One size might
stretch to fit all, but it's not necessarily
the best fit for everything.

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