Re: Question on pcase

[Oleh Krehel <ohwoeowho@gmail.com>]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Oleh Krehel <ohwoeowho@gmail.com> writes:
>
>> The reason I dislike `pcase' is not because I don't know how to use it
>> (the basic rules are actually pretty simple), it's because I think it
>> leads to code that's hard to understand, maintain and transform. I
>> dislike the trivial `if-let' and `when-let' for the same reasons.
>
> I like them because I think they make code easier to understand and
> maintain.

We can agree to disagree on this point. If I get an option to step into
a `pcase', I'll be able to work with it just as well as with
`cond'. I'll still never use it, but that's not the point. The point is
that I have to interact with `pcase' code if I want to edit the Emacs
core.

>> I generally dislike any custom macro that includes `if' or binds
>> variables. This is because I can't reason about the code that uses these
>> macros unless I know exactly what they do in terms of binding variables
>> and selecting branches. These macros don't follow the substitution model
>> for procedure application (SMPA) [1], which is a valuable debugging
>> technique for me.
>
> I wonder how you debug.  With the built in debugger, with edebug,
> something else?  Knowing that would help understanding you problem.

I debug with lispy [1], my package for Elisp and stuff. It's just a
sophisticated "C-x C-e" - all the program stack is in the global
variables.  If you'd like to try it, simply press "p" on consecutive
sexps to debug, e.g. "pjpjp". You can set up an initial stack with
`edebug': just "xe" on a function, evaluate something that calls it to
trigger `edebug' and press "Z".

>> Maybe someone could explain the above, and also suggest the best way the
>> create variable bindings from a pcase branch.
>
> `macroexpand' is your only choice if you want to have semantically
> equivalent code you can actually run.

`macroexpand' is the equivalent of stepping into a function call, when
you want to just call the function instead and examine the return
result. That's exactly my point about SMPA: you can only
eval-and-replace this whole huge `pcase' construct at once, you can't
decompose and evaluate it by parts. This should be done better.

> If arbitrary `pcase' forms could be expanded to simpler code, well, we
> should rewrite `pcase' to expand to this simpler code.

I'd prefer "we should use the simpler code", but your suggestion is a
step in the right direction as well :)

thanks,
Oleh

[1]: https://github.com/abo-abo/lispy