From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7885 invoked from network); 15 Dec 2007 05:56:40 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 15 Dec 2007 05:56:40 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 55617 invoked from network); 15 Dec 2007 05:56:34 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 15 Dec 2007 05:56:34 -0000 Received: (qmail 24225 invoked by alias); 15 Dec 2007 05:56:30 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24260 Received: (qmail 24213 invoked from network); 15 Dec 2007 05:56:30 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 15 Dec 2007 05:56:30 -0000 Received: from virusfilter.dotsrc.org (bifrost [127.0.0.1]) by spamfilter.dotsrc.org (Postfix) with ESMTP id E8EE18058F54 for ; Sat, 15 Dec 2007 06:53:37 +0100 (CET) Received: from vms048pub.verizon.net (vms048pub.verizon.net [206.46.252.48]) by bifrost.dotsrc.org (Postfix) with ESMTP for ; Sat, 15 Dec 2007 06:53:37 +0100 (CET) Received: from torch.brasslantern.com ([71.121.18.67]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JT200A7MTTXEIE2@vms048.mailsrvcs.net> for zsh-workers@sunsite.dk; Fri, 14 Dec 2007 23:56:22 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id lBF5uKcr002190 for ; Fri, 14 Dec 2007 21:56:21 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id lBF5uJQb002189 for zsh-workers@sunsite.dk; Fri, 14 Dec 2007 21:56:19 -0800 Date: Fri, 14 Dec 2007 21:56:19 -0800 From: Bart Schaefer Subject: Re: PATCH: internal parameter flags (resend) In-reply-to: <200712141014.lBEAEmZt001008@news01.csr.com> To: "Zsh Hackers' List" Message-id: <071214215619.ZM2188@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <20071213204318.2ff3e43c.p.w.stephenson@ntlworld.com> <071213204651.ZM446@torch.brasslantern.com> <200712141014.lBEAEmZt001008@news01.csr.com> Comments: In reply to Peter Stephenson "Re: PATCH: internal parameter flags (resend)" (Dec 14, 10:14am) X-Virus-Scanned: ClamAV using ClamSMTP On Dec 14, 10:14am, Peter Stephenson wrote: } Subject: Re: PATCH: internal parameter flags (resend) } } Bart Schaefer wrote: } > schaefer<506> typeset -Z 5 -T ARY ary } > schaefer<510> ary=(1 2) } > schaefer<512> echo $ARY[3] } > 00002 } > } > With PWS's patch applied, $ARY[3] becomes "1" in this example, which } > I believe is wrong. (I don't really think 00002 is correct either; } > in fact I'd have said it should just be "2". Why should the padding } > flags of the entire string apply to a slice of it?) } } I agree that the old value is wrong, but I don't see why the new value } is. You're now trying to add yet another rule that the padding flags } are sometimes ignored. Sorry; no, I'm not; that was just a remark in passing, it has nothing really to do with the point I was making. Please ignore it for this thread. } > This is distinct from ${${ARY}[3]}, which always was "1". } > } > } % typeset -u param=upper } > } % UPPER=VALUE } > } % print ${(P)param} } > } } > } prints nothing, even though $param outputs UPPER, because of the way } > } flags are handled in the wrong place. } > } > Again I think this was correct as it was. } } I really can't see how. I think it just creates a confusing } distinction on how parameters are accessed. Why would you set the -u } flag for a parameter and then expect it not to be applied? What's } the point in having both flags on substitution and on parameters } themselves if the latter only apply at the same time? I would set it to save me from having to remember to do ${(U)param} every time I mention $param, regardless of what order the flags are applied ... but mentioning $param and mentioning ${(P)param} aren't the same thing. } > ${(P)param} and ${(P)${param}} should be distinct, because the first } > uses the value of $param as a name whereas the second treats the } > substitution of $param as a name. } } To me that's just plain confusing. Let's consider a parallel situation: Parameter references in math expressions. If I write: setopt octalzeroes integer -Z5 x=9 Then $(( x )) has the value 9 but $(( $x )) is "bad math expression". Why wasn't the parameter flag applied to x in the first case? Do you think I should have expected it to be? What if x was not an integer? So, although I still think that ${(P)param} should use the un-altered value [*], I'm willing to let the other part of this go because of the following bad inconsistency with the "old way": torch% typeset -Z5 x=6 torch% print $#x 5 torch% print $x[4] torch% Either $#x should report the "real" length, or $x[4] should index into the string whose length was counted. I suspect that changing $#x in this case would break a lot more things than changing the subscript. [*] In part because they're the closest thing we have to namerefs, and namerefs would not allow these kinds of transformations on the value.