Re: Instead of pcase

[Michael Heerdegen]

Richard Stallman <rms@gnu.org> writes:

> I read the Info documentation of pcase a few days ago and I can't
> recall the rules for understanding those two pcase clauses.  What I
> recall is that they are not to be interpreted as Lisp expressions.

> They contain code that looks like Lisp but does not have the same
> semantic rules as Lisp.
>
>     `(,_ . ,(and (pred functionp) f))
>
> is not Lisp.
>
>     `(,hookfun . (,start ,end ,collection . ,plist)
>
> is not Lisp either.

I more and more come to the conclusion that the backquote syntax is more
or less the central point that scares or confuses (some) people.

So you would rather prefer to have a normal function that returns a
matcher (if you want just "Lisp")?

What functions could be used to describe a pattern matching lists of a
certain structure?  I guess it would be the easiest approach if we could
still use the names we already know: list, car, cdr.  Hmm - actually the
most compact mean to construct more complicated lists is backquote.  And
that's what you have above.  The only thing you need to remember is that
elements you "insert" or "splice in" are again pattern descriptions
matching the elements at that position.  How could it be even simpler?
Once you accepted that backquote is used for a different, but parallel
semantics here, everything suddenly gets absolutely trivial.

But I see your point, it's not Lisp.  I guess it should be possible to
change that.  We could define a set of functions to construct a matcher.

This would make the pattern specifications less compact and for some of
us harder to read (more verbosity), but it should be possible.  We could
even have some kind of converter between the two representations of
pattern specifications.  This leads me to a realization:

A "normal Lisp" approach would still need to define replacements for all
of the constructs.  (pred FUN . ARGS) would have to be replaced by
something like (make-matching-fun FUN &optional ARGS).  You would
still have to remember the exactly same details: what are the semantics
of the returned pattern; when there are ARGS specified, at which
argument position is the matched thing specified when FUN will be
called?  How to correctly negate this pattern?  Will the matching
algorithm backtrack when the pattern is negated?

So, the advantage would be more of a psychological kind: you have normal
Lisp function calls, but structurally you have the same thing, and you
have to remember exactly the same set of details.  The complexity comes
from the task, not from the implementation.


Michael.