From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11226 invoked by alias); 20 Jul 2017 17:40:47 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 41442 Received: (qmail 21232 invoked from network); 20 Jul 2017 17:40:47 -0000 X-Qmail-Scanner-Diagnostics: from mail-qt0-f170.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.216.170):SA:0(0.5/5.0):. Processed in 5.057256 secs); 20 Jul 2017 17:40:47 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_SPAM,SPF_PASS, T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.216.170 as permitted sender) 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== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uUQiz/7dyOZHB/Pwov2oicFKW2mgYbiDMCnYOKeZPPU=; b=AcdDAPqmD9Rn//2xmBfdebmR0uIm0YnxuNr1zUmAF3j4eOVpzMg8utDdRVg+6yebXV oV021lgJwegAFuX0gnCljSZUrGTMS4MBsTtK5MG6XWi5HPv0UKheFE7V1Ym6ktae/G6M IT2sz9aUUDeZDN99CVDRU1TbHb+7bPojG25N2It4HCxwm3nXwuO0U19/RZe3uxYrOORx Nle6Z5BbPm1+olXJwbiBqS9LLS9NHf4tZu6NwV204JmpYLNUOmhBsp3Ca1NVGGDu1XD9 QrIQPOgw7UBhaAoQFnl+wD9QV/6rYLMat+3aCm9+eIF4bHhtk63NhwMAytIBJ4h/U7kK G39w== X-Gm-Message-State: AIVw110hb8O+YAqjgdRJETaUSTvwhhOZgtQVhK+Ppy8OIHaWygEHJDWe LLwYuRwFz+HV0VRgTtU5u1FdKwTsHOWbeAI= X-Received: by 10.200.51.129 with SMTP id c1mr6200375qtb.71.1500572434696; Thu, 20 Jul 2017 10:40:34 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Bart Schaefer Date: Thu, 20 Jul 2017 10:40:33 -0700 Message-ID: Subject: Re: Can ZWC be optimized, for lesser depths of recursive exec* calls? To: Sebastian Gniazdowski Cc: "zsh-workers@zsh.org" Content-Type: text/plain; charset="UTF-8" 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. 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).