From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23253 invoked from network); 7 May 2007 01:00:37 -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; 7 May 2007 01:00:37 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 58779 invoked from network); 7 May 2007 01:00:31 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 7 May 2007 01:00:31 -0000 Received: (qmail 16434 invoked by alias); 7 May 2007 01:00:27 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23395 Received: (qmail 16424 invoked from network); 7 May 2007 01:00:27 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 7 May 2007 01:00:27 -0000 Received: (qmail 58457 invoked from network); 7 May 2007 01:00:27 -0000 Received: from mtaout02-winn.ispmail.ntl.com (81.103.221.48) by a.mx.sunsite.dk with SMTP; 7 May 2007 01:00:24 -0000 Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20070507010022.XJPU12560.mtaout02-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Mon, 7 May 2007 02:00:22 +0100 Received: from pwslaptop.csr.com ([81.107.41.251]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20070507010022.DGEM219.aamtaout01-winn.ispmail.ntl.com@pwslaptop.csr.com> for ; Mon, 7 May 2007 02:00:22 +0100 Received: from pwslaptop.csr.com (pwslaptop.csr.com [127.0.0.1]) by pwslaptop.csr.com (8.13.8/8.13.7) with ESMTP id l470wrfU010024 for ; Mon, 7 May 2007 01:58:53 +0100 Message-Id: <200705070058.l470wrfU010024@pwslaptop.csr.com> From: Peter Stephenson To: zsh-workers@sunsite.dk Subject: Re: [PATCH] Proposal: stat -> zstat In-Reply-To: Message from Phil Pennock of "Sun, 06 May 2007 07:00:00 PDT." <20070506140000.GA80030@redoubt.spodhuis.org> Date: Mon, 07 May 2007 01:58:53 +0100 Phil Pennock wrote: > Is it worth adding to the spec that the features will be processed > left-to-right, so that interactions between features will work? Eg, > disable all except certain aspects? Most modules will never use this, > thankfully. For now, features are likely to mean individual features rather than groups, but it certainly makes sense to specify they'll be parsed left to right at the outset. > zmodload -F zsh/pcre -:builtins :condops > zmodload -F zsh/files :files -mv :fs > > (hypothetically putting "sync" in an ":fs" category) > > And yes, the : as a part of the name instead of a separator is > distinctly un-shell-like, I use it here only so that those similarly > afflicted will understand what I mean. I was actually thinking of using ":" but in a different way: "b:" for a builtin, "p:" for a shell parameter, "c:" for a condition, "m:" for a math function, so you'd do zmodload -Fi zsh/stat b:zstat in the case in question. The main reason for this is to disambiguate the different namespaces. It would be natural to allow zmodload -mFi zsh/stat 'b:*' which is very similar to existing syntax. So I suppose that means we could ensure that something like zmodload -mFi zsh/stat 'b:*' -b:stat would work (load all builtins but disable "stat"). However, explicitly disabling things gets us back in the mess we've just climbed out of---each chunk of code knows what it needs, and should be able to request only those features, but doesn't know what the rest of the shell needs or doesn't need, so should just leave those alone. (Unless we can come up with a rule where we take the net effect of a set of patterns and then apply them, so that b:stat ends up being left alone. I think that's going to be too complicated.) > On the other hand, arguing devil's advocate, what would the feature > infrastructure provide that's not already available via zsh/parameters > and use of enable/disable? Natural integration of shell code using different features. The disable business, as you've already spotted, is not a very pleasant way of getting rid of a bit you don't want, since someone else may want it and not expect it to be disabled. Explicit feature requests act separately and fit together without any special action. -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/