Re: Regexp bytecode disassembler

[Štěpán Němec]

On Sun, 22 Mar 2020 18:55:53 +0200
Eli Zaretskii wrote:

>> From: Štěpán Němec <address@hidden>
>> Cc: address@hidden,  address@hidden
>> Date: Sun, 22 Mar 2020 15:43:03 +0100
>> 
>> IMHO the complexity of `pcase' is completely transparent in this case:
>
> 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.

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?

>> you can easily check the expansion e.g. with M-x
>> pp-macroexpand-last-sexp
>
> 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).

The macroexpand check suggestion was addressing the "economy" or avian
warfare concerns (it expands to the simple cond form), or those who want
to check if the intuition matches reality.

In any case, you seem to still focus on the "why _pcase_" issue, which I
thought was really a minor point here, and was never what I argued for
specifically, instead of the "why _some_ case/switch rather than cond".

-- 
Štěpán