[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on pcase
From: |
Oleh Krehel |
Subject: |
Re: Question on pcase |
Date: |
Tue, 27 Oct 2015 09:42:33 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
Michael Heerdegen <address@hidden> writes:
> Oleh Krehel <address@hidden> 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
- Re: pcase docstring tweaks, (continued)
- Re: pcase docstring tweaks, Michael Heerdegen, 2015/10/28
- RE: Question on pcase, Drew Adams, 2015/10/24
- Re: Question on pcase, Alan Mackenzie, 2015/10/24
- RE: Question on pcase, Drew Adams, 2015/10/24
- Re: Question on pcase, Johan Bockgård, 2015/10/24
- Re: Question on pcase, Michael Heerdegen, 2015/10/24
- Re: Question on pcase, Oleh Krehel, 2015/10/26
- Re: Question on pcase, Michael Heerdegen, 2015/10/26
- Re: Question on pcase, Oleh Krehel, 2015/10/27
- Re: Question on pcase, Michael Heerdegen, 2015/10/26
- Re: Question on pcase,
Oleh Krehel <=
- Re: Question on pcase, Michael Heerdegen, 2015/10/27
- Re: Question on pcase, Michael Heerdegen, 2015/10/27
- Re: Question on pcase, Michael Heerdegen, 2015/10/28
- Re: Question on pcase, Oleh Krehel, 2015/10/29
- Re: Question on pcase, Michael Heerdegen, 2015/10/29
- Re: Question on pcase, Andreas Schwab, 2015/10/26