zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Sebastian Gniazdowski <psprint@zdharma.org>
Cc: "zsh-workers@zsh.org" <zsh-workers@zsh.org>
Subject: Re: Can ZWC be optimized, for lesser depths of recursive exec* calls?
Date: Thu, 20 Jul 2017 10:40:33 -0700	[thread overview]
Message-ID: <CAH+w=7Y0Ay4npcWhtbHHhG5KA-C+0hsX1NioSnn635FBOYkVZQ@mail.gmail.com> (raw)
In-Reply-To: <etPan.5970cf0e.4c5f2547.6b4@zdharma.org>

On Thu, Jul 20, 2017 at 8:41 AM, Sebastian Gniazdowski
<psprint@zdharma.org> 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).


  reply	other threads:[~2017-07-20 17:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-20 15:41 Sebastian Gniazdowski
2017-07-20 17:40 ` Bart Schaefer [this message]
2017-08-19  5:06   ` Sebastian Gniazdowski
     [not found] ` <etPan.5970eb83.495b9d04.6b4@AirmailxGenerated.am>
2017-07-25  1:26   ` Sebastian Gniazdowski
2017-07-25  5:04     ` Bart Schaefer
2017-07-25  5:42       ` Sebastian Gniazdowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7Y0Ay4npcWhtbHHhG5KA-C+0hsX1NioSnn635FBOYkVZQ@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=psprint@zdharma.org \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).