From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24667 invoked from network); 9 May 2007 17:19:43 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=no version=3.2.0 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 9 May 2007 17:19:43 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 82831 invoked from network); 9 May 2007 17:19:36 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 9 May 2007 17:19:36 -0000 Received: (qmail 29486 invoked by alias); 9 May 2007 17:19:34 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23403 Received: (qmail 29477 invoked from network); 9 May 2007 17:19:33 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 9 May 2007 17:19:33 -0000 Received: (qmail 82515 invoked from network); 9 May 2007 17:19:33 -0000 Received: from vms044pub.verizon.net (206.46.252.44) by a.mx.sunsite.dk with SMTP; 9 May 2007 17:19:29 -0000 Received: from torch.brasslantern.com ([71.116.88.130]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JHS00I46ASAV5F3@vms044.mailsrvcs.net> for zsh-workers@sunsite.dk; Wed, 09 May 2007 12:19:23 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id l49HJLaI012393 for ; Wed, 09 May 2007 10:19:22 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id l49HJLct012392 for zsh-workers@sunsite.dk; Wed, 09 May 2007 10:19:21 -0700 Date: Wed, 09 May 2007 10:19:21 -0700 From: Bart Schaefer Subject: Re: [PATCH] Proposal: stat -> zstat In-reply-to: <20070508154018.9043aaca.pws@csr.com> To: Zsh hackers list Message-id: <070509101921.ZM12391@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <20070503053952.GA1481@redoubt.spodhuis.org> <070503074822.ZM24666@torch.brasslantern.com> <20070503164614.497b44d1.pws@csr.com> <070506223140.ZM9183@torch.brasslantern.com> <20070508154018.9043aaca.pws@csr.com> Comments: In reply to Peter Stephenson "Re: [PATCH] Proposal: stat -> zstat" (May 8, 3:40pm) On May 8, 3:40pm, Peter Stephenson wrote: } } In my reply to Phil I suggested using a convention like b:zstat, } p:functions, f:sin, c:-pcre-match, etc., to get around namespace } problems. It's quite possible we don't have clashes at the moment, } but it's entirely conceivable a module may export both a builtin } and a parameter with the same name. I think ":" is a good choice } here---doesn't need quoting, used in a similar way for styles---but } I'd be happy to entertain alternatives. I agree that ":" is a good choice; "." is the other obvious possibility, but we probably want to reserve that for ksh-style parameter namespaces. } This ought to be transparent to the main shell; it just passes down a } feature name to be handled by the module... Right. } Suppose: } } zmodload -ab zsh/nosh fishfingers } } is defined to be equivalent to } } zmodload -Fa zsh/nosh b:fishfingers This makes perfect sense. } and we document that the the second form is preferred? In other words, } the -a addition to the feature mechanism *does* require the name to } be in the form :, and generates an autoload } request of the appropriate type (or an error if it doesn't recognise } the prefix). This is also related to the question of whether a module feature can represent a collection of things. Could zmodload -Fa zsh/nosh turtleteeth mean e.g. "autoload anything related to turtleteeth"? I suppose that would mean loading zsh/nosh immediately, but with everything disabled, in order to find out what is contained in that feature. (And then unloading it again? Hrm.) Or else abstract features are in their own category, but then how do you know when to autoload them? For the first pass, or even the second, perhaps abstract features should not be auto-loadable. Which brings up a point: Previously modules were either all there or all not, except insofar as certain bits could be hidden by explicitly using "disable" after loading. With the features change we can get into the condition of the module being present, but invisible. } One extra tweak at least is needed: if we loaded a module through the } new form of autoload, we only enable any features explicitly requested } in that list. For compatibility the old form would fully load the } module (it may well be that a function assumes that autoloading one } builtin will bring in a whole load of others). What happens if both -Fa b:turtleteeth and -ab turtleteeth have been executed prior to the first attempt to find turtleteeth? The easy way out is to do the maximal load that has been previously requested. Random possibly unrelated thought: We might want to think ahead to the possibilty of module scopes (like the local parameter scope). } Presumably } } zmodload -ab zsh/nosh b:fishfingers } } should generate an error Since ":" isn't valid in an identifier I think that's OK. (Have we yet discussed whether symbolic conditionals like "=~" could be autoloaded?) } > Can features (or the user, with zmodload -d) declare that they } > depend on other features (of the same or other modules)? } } Urk. The current dependency mechanism is per-module and if we're going } to keep it then to do it properly we need it to be per-feature. If } each *feature* in the target module can depend on a feature in another } module it gets very hairy even to specify. I'm actually most concerned with the C definition of the module being able to specify dependencies, rather than the user being able to do so with some tangled zmodload -d syntax. } Although this is a significant question, I think we could implement } module features without this initially Yes.