From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4821 invoked by alias); 3 Oct 2015 23:44:07 -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: 36765 Received: (qmail 29174 invoked from network); 3 Oct 2015 23:44:05 -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=qLnRdJV31Jr4FH/TZ0PKW50Py8RlP3jtn9x3QRE35/Q=; b=e6RCYyayhgIwB5FM00GsxKlep0UZwhNWa99yLlzbDKv/qeZGQqpnPRelpVmsSzQRvs 2DOkv0YoE9IkRF5jQm7rmrurQWfegXEUCLNhMp1sBKgdJ90e1tmI8LP+refMKtaUMf7t iUH4/ioCtCGewkg5dr4hh3mJtToOa8YsHxQwEKcy4wxLF9DVj/BNSQlptlzTF6vp0/tG H4pBCqVDjEDlQR72RJ7mppc0Jtt0D3zM2QHRpmitiiDLxR9RzyCmlFxd2j2JgtrUPlHm sa0arlMip9ABsnWF9Brl9pXXRneooAgtL9xEpwimXfavUzSq3xlKaMyhhFaJkxazWy+Y V3QQ== X-Gm-Message-State: ALoCoQlL9vqICvhbHoba9DYABV7f4w97qsG2jLGrVubR73BwCMb0LGyIldHFSWww+I52JKGkd6LO X-Received: by 10.60.15.2 with SMTP id t2mr13012509oec.71.1443915841762; Sat, 03 Oct 2015 16:44:01 -0700 (PDT) From: Bart Schaefer Message-Id: <151003164358.ZM4868@torch.brasslantern.com> Date: Sat, 3 Oct 2015 16:43:58 -0700 In-Reply-To: <20151003201936.29b52aa4@ntlworld.com> Comments: In reply to Peter Stephenson "Re: Proof of concept: "static" parameter scope" (Oct 3, 8:19pm) References: <150924192305.ZM2680@torch.brasslantern.com> <20150925101540.5d2ded9c@pwslap01u.europe.root.pri> <20150930203825.307d3f8f@ntlworld.com> <150930172748.ZM3986@torch.brasslantern.com> <20151003201936.29b52aa4@ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Autoloaded keywords (Re: Proof of concept: "static" parameter scope) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 3, 8:19pm, Peter Stephenson wrote: } Subject: Re: Proof of concept: "static" parameter scope } } 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? Yes, that's sort of it. I was expecting a different error in the event that they'd been interpreted as glob qualifiers, so I assumed they had not been. } 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 } - 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). The latter would be fine if we're just talking about "private" and as has been mentioned we could pick up some efficiencies by adding a real PM_PRIVATE flag bit (though we are running out of PM_* bit positions). However, if we're talking about generalizing the mechanism, we can't reasonably assert that we'll enable every module-defined keyword via a change to the default distribution. I'm leaning toward } - document it and live with it but another thought is to in fact add autoloadable keywords as a module "feature" type and check every word as it's parsed to see if it needs to trigger an autoload. This shouldn't be that much worse than checking every word to see if it's an alias (and has the same pitfalls ... in fact in ksh many of what we have harcoded as builtins are implemented [or at least documented] as aliases). } - decide it's too hairy and limit ourselves to autoloading an option to } local etc. I hadn't considered autoloadable *options* ... how would that work? Here's yet another idea -- perhaps an extension of "autoload" that specifies which modules have to be zmodload'd before the function can be autoloaded and run. Correspondingly the in-memory function image would record the set of modules that were loaded when it was parsed, sort of like sticky options, and would return a runtime error if those modules were no longer loaded. (Or perhaps only if it were unable to REload them, but that might be too much automation.) We'd have to be sure that zcompile wrote out that state. (Does it now preserve sticky options?)