Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Can ZWC be optimized, for lesser depths of recursive exec* calls?



On Thu, Jul 20, 2017 at 8:41 AM, Sebastian Gniazdowski
<psprint@xxxxxxxxxxx> wrote:
>
> - Zsh code execution is emerging from from rich number of calls to exec.c functions,
> - general-purpose or not-final calls are done, equilibrium is established, each Zsh script part finds its (convoluted) way to execsimple, prefork, addvars,
> - like in Prolog (but maybe in reversed direction), where each theorem finds its top truths in many stages.

To some extent you're having a deeper variation of the same confusion
that Ray Andrews sometimes has, namely, distinguishing characteristics
of an interpreted language from a compiled one.  With a true compiled
language, the syntax and semantics can both be analyzed at compile
time, but in an interpreted language the semantics aren't fully
expressed until run time.  In this case the chain of exec.c function
calls traces the semantics of the language -- reconstructing the parse
tree, traversing it, and executing it, all at the same time.

This is crucial for accurately reproducing the original script flow in
xtrace output.  Simplifying the ZWC would amount to rewriting the
script -- looking at xtrace output would be like stepping through an
optimized C program with a debugger:  the program counter would no
longer correspond to the source.

Even if you are willing to accept that, there are a number of
potential gotchas with any shortcutting of the process -- witness
issues found in the past several months with signal handling, job
control management, propagation of environment variables, etc., some
of which arose because of the optimizations that are already present.

> some exec.c-reading hints, that the "not-following by WC_SUBLIST" means no-argumets for executed function, builtin, etc.

I think that's a wrong interpretation -- WC_SUBLIST should mean a
construct like "command1 && command2", where SIMPLE means there is no
such conditional construct (only "command1" is present).



Messages sorted by: Reverse Date, Date, Thread, Author