Re: pcase vs. case (where it could also be used) [Was: Re: Replace trivial pcase occurrences in the Emacs sources]

[Stefan Monnier]

>> - if you forget to quote your constant symbols the code behaves
>>   differently (and arguably surprisingly for some user) rather than
>>   giving you an error, tho in many cases the macro will detect a problem
>>   and give you a warning about a subsequent redundant branch (but the
>>   unsuspecting user will likely find it puzzling and it will take
>>   a while for him to figure out what's going on).
> Aren’t non-quoted for bind? what should give an error or a warning?
> I didn’t understood?

If the naive user wrote

    (pcase X
      (a fooa)
      (b foob))

when the intended behavior was

    (pcase X
      ('a fooa)
      ('b foob))

pcase will give a warning during macro-expansion that the second branch
is redundant (since the first branch matches everything already).

So, in a sense the user's error is detected, but the resulting warning
is hard to understand if you don't know that the pattern `a` matches
everything and binds it to the variable `a`.

> Also, in either pcase or case: can’t they eval a symbol as a variable
> value to be used in tests?

Sorry, I don't understand what you mean: X can be a variable that's
evaluated, yes.  Or do you mean the case where we want to test equality
with Y?  `pcase` can do that with

    (pcase X ((pred (equal Y)) foo-equal-Y) ...)

but I think this is irrelevant for the discussion at hand.

> To push the reasoning on an extreme:

Given Turing-equivalence, I don't think pushing the reasoning to the
extreme will be a good guide.

>> - once you learn it, you can use it elsewhere, e.g. pcase-let,
>>   pcase-dolist, ...
> Could have been the same for cl-destructuring-bind.

Except cl-destructuring-bind only covers (a subset of) pcase-let.
It could cover pcase-let as well pcase-dolist, but not `pcase` itself.
[ And even then, it would be less flexible than pcase-let because the
  syntax of cl-destructuring-bind's patterns doesn't leave much space
  for extensions.  ]

> You forgot simplicity and concision of implementation: easier to
> understand and reimplement, thus more hackable upon and widespread.

I don't think it's particularly important, indeed.

> For instance, I personally have my own case* implementation for using
> other test-fn than eql (such as equal,

That highlights the problem that cl-case doesn't work with strings,
forcing users like you to write their own alternative.

> the only possible one for pcase, and I don’t even hope making my own
> version for eq/eql/etc.).

Could you show me a pcase pattern where pcase's choice of equality
is problematic?
[ FWIW, there's only one case to comes to my mind.  ]

>> - easier for people who already know Common-Lisp (or those who learned
>>   `case` from the cl.el package).
> Also it is basically the equivalent of “switch/case/etc.” many will
> search for, coming from another language such as C: and not everybody is
> fond of destructuring and pattern matching

pcase works just as well to replace "switch/case/etc."
You don't have to use pcase's destrucuring, and this discussion is about
the subset of case covered by `cl-case`, so destructuring is outside of
its scope, AFAIC.

>> - in (case X (a fooa)), the syntax looks a bit like a call to the
>> function `a`: emacs-lisp-mode gets confused in terms of highlighting
>> and completion, last I checked.
> case is a macro: why making assumption on calls in macros arguments?
> from time case known as a macro (I’ve a hard time imagining what a
> “case” *function* would be anyway)…  Also, with an unquoted symbol (so
> to bind the default case), you have this very same problem with pcase:
> (pcase X (a (fooa))) (and emacs syntax highlighting is confused here

Not again that the pattern `a` here is outside the scope of this
discussion (except to the extent that user can write it by mistake).


        Stefan