Re: Regexp bytecode disassembler

[Eli Zaretskii]

> From: Štěpán Němec <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Sun, 22 Mar 2020 18:16:58 +0100
> 
> > I disagree.  And please also consider the easiness (or lack thereof)
> > of changing the code, not just reading it.  pcase is far from being
> > simple, its syntax is tricky to understand fully.  it's no accident
> > that it took us 2-3 iterations and many discussions to converge on
> > what is now its documentation.  Just the volume of that documentation
> > should tell you how NOT transparent is its complexity.
> 
> Changing code that _uses_ pcase doesn't involve changing code that
> implements pcase, unless I'm missing something.

It depends on the change.  And in any case, how can you reliably
change code whose syntax you don't sufficiently understand?

> Given that using pcase here makes the code in question shorter (and for
> most of those who commented apparently also more readable) compared to
> the cond version, doesn't that _add_ to the easiness of changing it?

For you and me, maybe.  But we must think of others.

I'm not saying we shouldn't use pcase -- we use it quite a lot in pur
sources.  I'm saying that using it where simpler, more basic
constructs will do reasonably well is more economical.

> > So you are saying that reading code should be accompanied by expanding
> > the macros it uses?
> 
> Certainly not. I already said that I believe the code was perfectly
> understandable even for people knowing nothing about pcase (at least in
> this case).

How can we, who master this already, know what is or isn't
understandable for people who don't?  I don't think we can.  You
cannot "unlearn" something, at least not easily.  The only practical
strategy is not to use devices that are overkill.