Re: Instead of pcase

[João Távora]

On Fri, Dec 1, 2023 at 11:52 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > So, in these emails, I'm trying to explain to you how to change your
> > view of these pcase constructs in a constructive way
>
> This is a misunderstanding: I'm not expressing _my_ views.  I'm
> expressing the views of someone who bumps into this code the first or
> the second time, and/or didn't yet have the advantage of someone
> giving them "a piece of insight" that caused you to change your mind.
> IOW, I'm expressing _your_ views before you changed your mind.

Fair enough.  Though, given your statements about the "redundancy"
of '.' and its different "magic" role in 'pcase' vs "elsewhere in Lisp"
one can be easily led to believe the contrary, because both those statements
are demonstrably false (at least in the only interpretation of them I
could find).

> In Emacs development and maintenance, being able to look at stuff from
> the POV of an innocent user or Lisp programmer is sometimes required
> to realize the true impact of some constructs and features.  We cannot
> regard that only from the height of our own knowledge and experience,
> which usually far surpass those of many Emacs users and programmers.

Again, this is perfectly fair.  Elisp, like many other languages,
has constructs for different levels of proficiency.  You wouldn't refrain
from using C functions or C typedefs just because it requires more knowledge
about the how the C language than a simple untyped program where everything
is inlined in main() and every piece of data is in an array.

> If this is that easy, then why do we need no less than 120 lines to
> describe pcase in the doc string, and no less than 600 lines to
> document its features in the ELisp manual?

_I_ didn't write that docstring.  Maybe the docstring and the manual
should start by making the easy and common use cases prominent and
visible, just like I tried to do in that 10 line paragraph.  As you know,
writing good docstrings and manuals is a challenge in itself.  But that
shouldn't  be an argument against the validity of the tool being
described.

> understand that.  None of that is true.  All I'm trying to say is that
> there _are_ inherent problems in the DSL whose knowledge is required
> to understand code written using pcase, and that you and others should
> recognize these inherent problems are real

The only _inherent_ difficulty I recognize in pcase DSL's is the _inherit_
difficulty in understand the backtick-and-quote in so-called "normal Lisp".

> , even though you have
> overcome them, and anyone could overcome them given enough time and
> experience.

My point is that "time and experience" isn't necessary to understand
the most common uses of pcase's DSL.  That one piece of insight paired
a knowledge about how backtick-and-quote works "in normal Lisp"
for list construction will suffice to fully master pcase's list
destructuring abilities.