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

[Sebastian Gniazdowski <psprint@xxxxxxxxxxx>]

On 20 lipca 2017 at 19:40:33, Bart Schaefer (schaefer@xxxxxxxxxxxxxxxx) wrote:
> On Thu, Jul 20, 2017 at 8:41 AM, Sebastian Gniazdowski
> 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.

It's just that I suspect "recurse and forget" tactics in exec.c. Like zle recursive-edit – surprisingly useful, implemented by running zlecore() second time. Having an opportunity to give kudos, I would give it to that person who decided to spend time on doing this very useful in the future, but in general slightly bizarre (running zlecore() again) feature.


The comment in exec.c (first line about suspending pipelines):

 * Some years ago, zsh either couldn't suspend such things at all, or
 * it got really messed up when users tried to do it. As a solution, we
 * implemented the list_pipe-stuff, which has since then become a reason
 * for many nightmares.
 * Pipelines like the one above are executed by the functions in this file
 * which call each other (and sometimes recursively). The one above, for
 * example would lead to a function call stack roughly like:
 *
 *  execlist->execpline->execcmd->execwhile->execlist->execpline

So it looks like getting away through recursion, which is a powerful technique, but if it's "recurse and forget", and CPU time dissipates, then well, no huge problem, shell doesn't have to be fast like python, but it is an obstacle sometimes (syntax highlighting large functions, for example, I was removing functions (inlining) and also simply removing code if only it was possible, gaining many milliseconds).

I have obstacles in working on Zsh recently, I would dive into exec.c and maybe find something. Side note – all this is to make Zplugin sophisticated, dreaming about automatic extraction of functions and "turbo" compilation of them into zwc digest. But "turbo" compiling of plugin file (with global code and functions) would also work, he he, so I would close this door for the users ;)

> > 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).

Thanks. It's a better situation than no-arguments, if one thinks about short-cutting execution more early to execsimple(), etc.

--  
Sebastian Gniazdowski
psprint /at/ zdharma.org