From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1262 invoked by alias); 3 Oct 2015 19:19:40 -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: 36762 Received: (qmail 20095 invoked from network); 3 Oct 2015 19:19:39 -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-Originating-IP: [80.3.228.158] X-Spam: 0 X-Authority: v=2.1 cv=TNS4MARa c=1 sm=1 tr=0 a=P+FLVI8RzFchTbbqTxIDRw==:117 a=P+FLVI8RzFchTbbqTxIDRw==:17 a=NLZqzBF-AAAA:8 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=iMZLd2K_3ZWu5nUJD_cA:9 a=MQR-NH23tMfJKi_L:21 a=trBC-OFzvxWl4OMx:21 a=CjuIK1q_8ugA:10 Date: Sat, 3 Oct 2015 20:19:36 +0100 From: Peter Stephenson To: Bart Schaefer Cc: zsh-workers@zsh.org Subject: Re: Proof of concept: "static" parameter scope Message-ID: <20151003201936.29b52aa4@ntlworld.com> In-Reply-To: <150930172748.ZM3986@torch.brasslantern.com> References: <150924192305.ZM2680@torch.brasslantern.com> <20150925101540.5d2ded9c@pwslap01u.europe.root.pri> <20150930203825.307d3f8f@ntlworld.com> <150930172748.ZM3986@torch.brasslantern.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 30 Sep 2015 17:27:48 -0700 Bart Schaefer wrote: > 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. What would make it a syntax error here? You haven't disabled globbing flags. It's only an error when you run it and get... > torch% zxxx > zxxx: number expected It's just the same as % zyyy() { burble x=(a b c); print $x } % zyyy zyyy: number expected as it should be. Maybe you'd forgotten that parentheses are parsed so as not to make white space work as a word separator? > Enabling the builtin again does not fix this: > > torch% enable -r local > torch% zxxx > zxxx: number expected Obviously, since it parsed the function zxxx when local wasn't a reserved word and you've done nothing to reparse it. You need to parse it again. % enable -r local % zxxx() { local x=(a b c); print $x } % zxxx a b c This is the point of the difference between reserved words (keywords that cause parsing to behave differently) and builtins (names of commands that are looked up when the command is about to be executed). This certainly doesn't help you make a syntactic structure dynamically loadable, but that's always going to be hairy. I think our choices are - document it and live with it - decide it's too hairy and limit ourselves to autoloading an option to local etc. - provide adequate means, probably turned on by default, to load everything early enough that it just works. This means the distribution would enable "private", or whatever, as a keyword out of the box. If we don't I don't think this is worth doing. (Of course you can still use disable -r in am initialisation file.) - go a step even further than that and just compile it in (but you can *still* disable -r). - or, I suppose, we could compile it in with disable -r applied, but then we're back with all the gotchas about needing to reparse if you use it. pws