Re: Instead of pcase

[Barry Fishman <barry@ecubist.org>]

On 2023-12-02 11:14:19 +01, Emanuel Berg wrote:
> I thought pattern matching with in particular Haskell was
> neurotic because one would spend more time on it than one felt
> was called for, but I think Haskell invited to that kind of
> fiddling, I always thought of Elisp including `pcase' to be
> much more calm and relaxed?

Your sense of calm and relaxation about `pcase' does not seem to be
shared by a lot of people, who think of it as overly complex and ugly.

To me Haskell starts with just Scheme changed to fix every criticism
that has been make about Lisp whether it was valid or not.  But they end
up with something very different.

The Haskell pattern matching construct, unlike `pcase' is broken into
three independent steps.  First the declaration of types for each of the
variables to be extracted, although this is sometimes done automatically
by the (static) type system.  Then, the list of accepted patterns, given
in the form of constructors using the variables to build the patterns
being matched. Then possibly a list of tests to be tried on the values
of the matching variables.  And finally for the first valid "pattern"
and "guard" test, the code is execute using the extracted variables.

My example `proto-case' more resembled this, although I did not allow
for multiple guard clauses for each constructor match.  It did not use
back-quoting, but instead required used a prototype constructions add
those needed for each atomic type, or type class (in the sense of CLOS).

This is less powerful than `pcase', but didn't require a subset of
back-quoting merged with modified type specifier syntax in one new
`pcase' specific language.

But comparing what goes on in Haskell `case' vs. any pattern matching in a
Lisp like language is hard, primarily because Haskell evaluation rules
are so different from those of other languages.  Haskell is a curried,
non-strict, statically typed, syntactically complex language, so can
reorder code in ways that are very different than Elisp.  So simple
Haskell code can becomes very complex in Lisp, and simple Lisp code can
be very complex in Haskell.

But my issue with `pcase' is more related to that people will tend to
use it by copying and pasting its example cases (which they don't fully
understand), in places where a simpler syntax would be used.  This is
partly because Elisp does not have the simpler Common Lisp `typecase'
(it does have the discouraged `cl-typecase') and a more flexible 'case'
and Scheme like `cond' constructs that are easier to understand and use,
and work in most situations.

Yes, you can come up with `pcase' situations that are shorter or more
powerful, but its seems that the `pcase' proponents don't seem to be
able to provide obvious examples which show that power.

Without those examples people will tend to cut and paste code in places
where simpler more readable code could be use.

Their use of pointing to existing Elisp code using `pcase' involves
understanding the context of the code.  This makes giving the any
alternative examples harder to do, because it require understanding and
possibly restructuring more complex situations.

Its should be the burden on the proponents of a new feature to provide
useful examples of their construct in a simple explainable context, and
not the alternative.

I see the Haskell pattern matching given very little time in
introductory Haskell books, because its well formulated and easy to
understand in the context of the language.

Of course understanding Haskell, especially after being exposed to most
other languages, requires a mental reset that is not easy.  It took me
about four re-reads to gain any understanding what was going on, but I
was burdened with having used a lot of other languages.  It was the
first time I couldn't just recast things in terms of how I would do them
better in Lisp.

But using a constructor based rather than a backquote-splice/type-specifier
approach seems (to me) simpler to understand.

Or at least give an example of code (in a simple context) to show
`pcase' in something that shows its full power.

-- 
Barry Fishman