Re: combining cond and let, to replace pcase.

[Michael Heerdegen <michael_heerdegen@web.de>]

Richard Stallman <rms@gnu.org> writes:

> Some of them could do destructuring as well as matching.
>
> I hoipe that using a few constructs to divide up the job will avoid
> the kludginess of pcase's bells-and-whistles-for-everything approach,
> resulting in something equally convenient but made of simple
> components.

I really don't know how you come to such a conclusion.

The original docstring of `pcase' was half of a screen page and it was
_complete_.  Syntax and semantics are simple, nearly trivial, and
consistent.  It took one minute for me to learn everything.  Then the
doc has been extended to the current form adding more prose, in my eyes,
it added not a single bit of information.

If some people have a problem understanding the abstract approach, this
is something different.  But a "kludginess of pcase's
bells-and-whistles-for-everything approach" does not exist.  So please
understand that your approach will make the situation worse for others.

To me this discussion looks like some people aren't willing to accept
multiplication like 10*5 because it "looks strange" and "one would rather
write "5+5+5+5+5+5+5+5+5+5" because this would be much simpler and we
don't need this strange "*" at all.

Is this unfair?  I don't know.  But are there any _objective_ reasons
why the design of `pcase' would not be optimal?  To me this all looks
more like being based on vague feelings because the approach is a bit
different from what people are used to.  But the approach is extremely
simple.  I think that replacing it with multiple other tools would
complicate the matter.


Any additionally defined pcase macros are a different thing of
course. They extend pcase patterns to a richer but more complicated
mini-language.  You need to remember more definitions.  OTOH, this is
not a design fault of pcase patterns: any matching tool that wants to
provide specialized tools to support matching of special things (like
structs) will have to extend the semantics in one way or the other, and
necessarily complicate the tool(s).


To sum up, I question your premise of this discussion.  In my opinion
`pcase' comes very close to the optimal solution for its task.  For
some reason, people don't accept the backquote syntax it uses, although
it perfectly fits the task of destructuring.  I just don't understand it.
People get crazy about that backquote.  Dunno what's the matter with it.
But it seems this is one of the main problems.


Michael.