emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Replace trivial pcase occurrences in the Emacs sources


From: Stefan Monnier
Subject: Re: Replace trivial pcase occurrences in the Emacs sources
Date: Tue, 23 Oct 2018 14:12:34 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> I think so too, but it seems the majority of developers has a different
> option, at least in this (old) thread.

So I guess I'm gonna have to try and argue my case.
OK, here are the advantages I see for `cl-case`:

- simpler doc because its functionality is much more limited.
- easier for people who already know Common-Lisp (or those who learned
  `case` from the cl.el package).
- more concise syntax for branches that match multiple constants.

Here are the problems I see with cl-case (regardless of pcase):

- some users naturally write (case X ('a fooa) ...) without realizing
  that it also matches thew `quote` value.
- tricky corner cases when trying to match the `t` or `nil` values (or
  `otherwise` as well, tho this one is much more rarely needed).
- 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.
- only works with numbers and symbols: can't use it to match against strings.

In the specific case of using `pcase` where `cl-case` could also be
used, the downsides I know of `pcase` are the following:

- because it can also do a lot more, its doc is much more complex.
- you have to use the more verbose ((or 'a 'b 'c) ...) syntax when
  matching several alternative values.
- 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).

The advantages are:

- it fixes all four problems I described about `cl-case`.
- it can accommodate many more cases, so it offers a smoother evolution.
  IOW, you will rarely find yourself having to stop using `pcase` and
  to rewrite the code to use `cond` instead just because you need to
  add a case that's a bit different from the others.
- once you learn it, you can use it elsewhere, e.g. pcase-let,
  pcase-dolist, ...
- Elisp+pcase is simpler than Elisp+clcase+pcase, so if we aim for
  overall simplicity we'd be better off without cl-case (to the extend
  that `cl-case` is too limited and hence we'll still want to use
  `pcase`).


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]