Re: combining cond and let, to replace pcase.

[Alan Mackenzie <acm@muc.de>]

Hello, Michael.

On Sun, Nov 19, 2023 at 12:20:20 +0100, Michael Heerdegen wrote:
> 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.

The original doc string of pcase was not a high quality one.  See the
thread in emacs-devel Subject: The poor state of documentation of pcase
like things, started by me on 2015-12-16.

Some of its deficiencies, listed in that post, were (i) Use of obscure
terms like U-pattern and Q-pattern which it failed to define; (ii) the
semantics of these structures was not elucidated; (iii) there was no
rigorous definition of what ` and , mean in pcase structures; (iv) there
was no specification of when a pcase pattern matched something; (v)
there was no specification of when and how variables got bound.

The doc string didn't say in accessible language what pcase does.

But I'm repeating myself.  It's all in that 8 year old post.

I may be mis-remembering, but I think it was you, Michael, who put in
the work to fix these defects in pcase's doc string.  The result was far
better than the original.

> 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.

pcase complicated the meaning of ` and ,.  Before pcase these had
definite meanings.  Afterwards, they became highly context dependent.
The usual evasive reply from pcase proponents here is that ` has always
been an abbreviation for backslash and that didn't change.  A lot
changed, here.  An alternative here would have been to invent new reader
macros instead of complicating and ambiguating ` and ,.

[ .... ]

> Michael.

-- 
Alan Mackenzie (Nuremberg, Germany).