Zsh Mailing List Archive
Messages sorted by:
Re: Can ZWC be optimized, for lesser depths of recursive exec* calls?
- X-seq: zsh-workers 41442
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Sebastian Gniazdowski <psprint@xxxxxxxxxxx>
- Subject: Re: Can ZWC be optimized, for lesser depths of recursive exec* calls?
- Date: Thu, 20 Jul 2017 10:40:33 -0700
- Cc: "zsh-workers@xxxxxxx" <zsh-workers@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uUQiz/7dyOZHB/Pwov2oicFKW2mgYbiDMCnYOKeZPPU=; b=Diwt7GSzoRGMSGpfSv8yzjP6nXsS7i7FdgHxlDNRPD2r5VvW9dzUmYIbb0IRMMbpxX wRkm430sbt1jFz95V8lHXPzhaf0uEYMkN2maWt7jaMXVNjMsqU/z5W6DjVfmuiPI0RSD 7dQXbfgg7AcQCtYW9HRMQthKU+joSbVD+rBAmUtygAMFASHV+3iySgtshm/S7G09zrcA z7PEFxJ+VSoG8Du6V2cJMKN26EpcUL7ZDy8B5uRPg/KzTUTE3g08rlu9MnpYApyfTJjI vTDaThQtWcgu/6I0W6PQTQIzT3X3r6pnlhT3TJoBD9VT6XPsKo7k8UOFWg9Nb5XUDOXW hDjg==
- In-reply-to: <etPan.email@example.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <etPan.firstname.lastname@example.org>
On Thu, Jul 20, 2017 at 8:41 AM, Sebastian Gniazdowski
> - 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: