From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17097 invoked by alias); 1 Oct 2015 00:27:55 -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: 36728 Received: (qmail 5318 invoked from network); 1 Oct 2015 00:27:54 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=En9xX5a8QJP2SPK0XkAi0OXuG9K2pyZ39g9oB0ltTmo=; b=bPkUAEey1luj3tC9c/0WM7R17KZx14IAlMFlCTkFLIBhRbIzDHZkVFiTh9p3C4Dsk4 /5GAD2ntl0xyC3V0iCxd6r/SU4LKaBdkUHMm6PnLgAb+VQ1iG3lqq0MGCjY56Sc6X3r2 Stw7gPH7b4qqzGmTPDsKxv0cJXBQPzelI9E1Yzipw3KkatzrL3v+g8UaKHrhJm3Wn2Un rMTEzbc33SrzJdkZZ6c8zMAkEWeXie/7Nc9XucRSAKasWJkrQngESnm3b5QCotlN96G2 uHHCS2Z8WoSZ7who5VohhVT3oncKrfrBijpHJEVPfLNGlv8FZlnWEPzmk3IdjCASWIss +E7w== X-Gm-Message-State: ALoCoQkGOT1hyhLgszoi2qJZJELOjDBB8MTsGVUFXjtD0nji6QO3syLqfWZ/Emss94jCIopZomo6 X-Received: by 10.202.58.85 with SMTP id h82mr3966611oia.69.1443659271630; Wed, 30 Sep 2015 17:27:51 -0700 (PDT) From: Bart Schaefer Message-Id: <150930172748.ZM3986@torch.brasslantern.com> Date: Wed, 30 Sep 2015 17:27:48 -0700 In-Reply-To: <20150930203825.307d3f8f@ntlworld.com> Comments: In reply to Peter Stephenson "Re: Proof of concept: "static" parameter scope" (Sep 30, 8:38pm) References: <150924192305.ZM2680@torch.brasslantern.com> <20150925101540.5d2ded9c@pwslap01u.europe.root.pri> <20150930203825.307d3f8f@ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Proof of concept: "static" parameter scope MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 30, 8:38pm, Peter Stephenson wrote: } Subject: Re: Proof of concept: "static" parameter scope } } I wonder if it's easier than that. If the builtin has the BINF_ASSIGN } flag then the module code could do that automatically without the module } needing to declare a different sort of feature. As long as the } interface is correct, simply adding a reserved word with the token } TYPESET should be enough. Indeed, simply calling reswdtab->addnode() from setup_() works fine. It doesn't really even need to be automated by the module code. } The trouble is it needs to know this early, because anything using this } builtin with the assignment interface needs to be parsed properly. In } particular, it would have to be registered as a reserved word at any } point it wsa marked for autoload. That is indeed a problem. It actually works much better to have the module overload "local" (my hack to add the -S [now -P] switch) because then the order of parsing the calling code and loading the module are independent. Also there are some interesting side-effects if you load the module, then define a function that uses the new keyword, and then unload the module again and replace the keyword with a function or an external command. Here's a confusing thing that's indirectly related: torch% disable -r local torch% zxxx() { local x=(a b c); print $x } torch% Eh? Why is that not a syntax error? The reserved word "local" has been disabled, yet x=(a b c) is still parsed as an assignment. torch% zxxx zxxx: number expected Enabling the builtin again does not fix this: torch% enable -r local torch% zxxx zxxx: number expected