Re: Instead of pcase

[Adam Porter <adam@alphapapa.net>]

Hi Richard,

> I think whoever wrote that code in byte-optimize-letX was fascinated
> by the challenge of writing as much as possible in pcase language
> and minimizing use of Lisp.
> 
> Here's my version, which I think is a lot clearer.
> 
> It illustrates some of the flexibility of cond*:
> * Use of ordinary Lisp fir conditions,
> * Matching against different objects.
> * Clauses that bind and then drop through.

Respectfully, I disagree that this example is clearer than the original 
pcase form.[0]  I'll explain why:

> (defun byte-optimize-letX (form)
>   (cond*
>     ;; Bindings list is empty.
>     (:match (`(,_ () . ,body) form)
>      `(progn . ,body))

This is nearly identical to the equivalent pcase syntax, only adding 
`:match'.  Since pcase's (and I suppose cond*'s) purpose is pattern 
matching, this seems redundant and unnecessarily verbose.

>     ;; Decompose the form
>     (:match (`(,head ,bindings . ,body) form))

I suppose it is largely a matter of taste, but I strongly dislike 
fall-through clauses.  While it seems convenient here, as it allows the 
removal of either a redundancy (reiterating bindings in multiple 
clauses) or a level of nesting, its bindings are also implicit rather 
than explicit, as the scope of the binding form is not enclosed by 
visible boundaries (i.e. parens).

One also wonders what it would look like if such a cond* form had 
multiple, overlapping fall-through bindings of the same variables--that 
would seem to be necessary in some cases, and would likely be confusing.

Finally, forms which allow fall-through clauses are known to be more 
prone to human error than forms which don't allow them--and they don't 
seem syntactically "lispy."  So I think this is more confusing than 
pcase, not less.

>     ;; Body is empty or just contains a constant.
>     (:match ((or `() `(,(macroexp-const-p const))) body)

This seems even more confusing to me.  The equivalent pcase form is:

   `(,head ,bindings . ,(or '() `(,(and const (pred macroexp-const-p)))))

While the `and' keyword's being used to bind `const' may be surprising 
to those unfamiliar with pcase,[1] at least it explicitly binds the form 
to the variable before using it, and the scope of the binding is visible 
(being within that clause).

In contrast, the cond* example appears to implicitly bind `const' by the 
symbol's being present in the predicate form as an argument.  This seems 
much less clear to me.  It also seems error-prone, as in a case where 
`const' were already bound.

As well, what if the user needed to pass an already-bound argument in 
addition to the one being bound there?  With pcase, the binding would be 
explicit, and the accompanying `guard' expression would have a clear 
place in lexical scope, so there would be no doubt about where the 
arguments were bound.  With cond*, would the binding apply to the first 
argument symbol or a later one?  If the goal is to avoid implicit rather 
than explicit behavior, that seems contrary to the goal.

For these reasons, this seems more confusing to me than pcase, not less.

Sincerely,
Adam

0: 
https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/byte-opt.el?id=75fd7550ed6cede6c9e8224f1f2d62637c43fdd4#n1459

1: Perhaps we could recommend a minor change to pcase that might improve 
understanding: a `bind' keyword could be used to explicitly bind 
variables, rather than only having the implied binding from the `and' 
keyword (since `let' already has a different purpose in pcase).  So the 
example from earlier could look like:

   `(,head ,bindings . ,(or '() `(,(and (bind const) (guard 
(macroexp-const-p const))))))