Re: Instead of pcase

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Sun, 19 Nov 2023 15:14:58 +0100
> 
> I'm curious how an alternative could look like, actually.

I don't know.  So I withdraw my judgment until such an alternative is
presented.  I suggest that everyone do the same.

> It would have to implement the same set of features, so it would be
> quite as complex as `pcase'.

Complexity doesn't necessarily mean cryptic syntax.  Cf regexp strings
vs Rx.

Cryptic syntax raises the bar by adding one more obstacle: before you
deal with semantic complexity, you need to fight the uphill battle of
syntactic complexity and obscurity.

> You would have to remember or look up more or less the same things
> and details.

But if "the same things" speak for themselves, because they are
identified in more human-readable language, you have fewer things to
look up.  Again, cf. regexp strings vs Rx.

> And here the `rx' example and `pcase' are very similar: what the
> programmer actually has to keep in mind is how the regexp matching
> algorithm or the pattern matching algorithm works.

That's true, but before you consider the subtleties of matching, you
need to understand what the regexp should match, and that is harder
with regexp strings when advanced features are used.

> In your example, actually, string regexps are the primitive, low level
> language, `rx' is the higher level language, so it should lead to less
> mistakes (your argument).  `pcase' is the extensible higher level
> language for pattern matching, specifically designed for this purpose,
> so it should be more suited and lead to less mistakes than more
> primitive tools.

To me, whether stuff is lower or higher in level is less relevant
here.  For example, macros can be considered "higher-level" constructs
than the underlying Lisp functions and primitives, but macros are
harder to read due to the additional syntax: the backticks, the comma,
the @, etc.

I'd say that higher-level languages always make it easier to write
programs, but don't necessarily make it easier to read them.  As
another data point, consider the C preprocessor macros and
specifically their advanced features, like # and ##.  I invite you to
try reading what we have in src/conf_post.h and src/lisp.h, and make
up your own mind.

> Has anyone counted how many mistakes were introduced by wrong pcase
> pattern specifications, compared to more verbose re-formulations using
> other tools?  If we don't do that, the discussion is still selective,
> with other words, about preferences again.

Should be good to do that, but please remember that pcase exists for
less than a decade, so we are just starting to learn to use it.