Re: Instead of pcase

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

>   >     ;; ALIST-VAL = '((:key1 . 1) (:key4 . 2))
>   >     ;; Match alist key where the key is one of a know set of keys.
>   >     (match* (memq (alist-get key alist-val) '(:key1 :key2 :key3)) :key1)
>
>   > >From the description of "constrained variable" construct, the above will
>   > (1) test if ALIST-VAL contains a record with KEY=:key1 key; (2) test if
>   > KEY=:key1 is one of :key1 :key2 :key3.
>
> What a strange example.  This is connterintuitive and I could not see
> at first what it would mean.  But I worked it out by following the
> rules.
> ...
> So the memq call would return t.  And the pattern would match,
> binding `key' to :key1.

> It isn't "wrong", but I can't see the point using that strange 
> pattern.  What purpose did you have in mind in writing it?
> Is there a simpler way to do that?

Let me try again to illustrate the point I wanted to make - the
(match* (PRED VAL ...)) construct can look too similar to ordinary Elisp
yet yielding different results that one would have to work out
consciously. This similarity may lead to confusion.

Consider another example:

(match* (xor (not var) t) t)

Unlike (match* (> (integerp bigger) 5) 10), where it is clear that
#'> cannot apply to the return value of #'integerp, my example with
#'xor may be tricky - one may confuse that #'xor is applied to the
return value of (not var) rather than to var itself.

More generally, my concern is that
(match* (PRED1 (PRED2 var) ARGS) val)
may be confusing for people reading the code because
(PRED1 (PRED2 var) ARGS) outside match* is also a valid Elisp code,
which returns a _different value_ compared to what happens inside
match*.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>