From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21234 invoked from network); 14 Jan 2002 12:45:36 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 14 Jan 2002 12:45:36 -0000 Received: (qmail 27958 invoked by alias); 14 Jan 2002 12:45:28 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16446 Received: (qmail 27946 invoked from network); 14 Jan 2002 12:45:27 -0000 Message-ID: <20020114124525.3912.qmail@web9301.mail.yahoo.com> Date: Mon, 14 Jan 2002 12:45:25 +0000 (GMT) From: =?iso-8859-1?q?Oliver=20Kiddle?= Subject: Re: PATCH: += parameter assignments To: zsh-workers@sunsite.dk Cc: schaefer@brasslantern.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sorry if you get this twice - I'm resending it after it didn't turn up first time and sorry if Yahoo re-wraps the text horribly. Bart Schaefer wrote: > I'm not entirely happy with the addition of the a+=val syntax because > it > conflicts (conceptually, not mechanically) with the += operator that is > already present in the math syntax. Consider that the following: > > integer i=4 > typeset s=4 > i+=5 > s+=5 > ((i+=5)) > ((s+=5)) > print $i $s > > yields > > 14 50 What would you have sooner expected - `14 14'? > > However, what I consider to be worse is that: > > s=four > ((s+=5)) > s+=5 > print $s > > yields > > 55 > > Interpreting strings as integers in math context makes some sort of > sense, but doing both that, and also overloading += depending on the > parameter type, is going too far. I think the suggested change for > -= would be even more confusing. I'm not sure that I've entirely understood your argument here as your example doesn't seem particularly confusing to me. The ((s+=5)) results in 5 with s remaining a scalar - that was the case before. It remained a scalar so the s+=5 results in 55. I don't think it is ideal that the new += can be used for numeric addition. I find += to be useful with arrays, scalars and associations and it is these (with the addition of compound variables) for which I imagine this feature was intended in ksh93. My intention was to continue to use (( ... )) when dealing with numerics - we could add a note to recommend this in the documentation. Have you got any ideas on how to solve this? Short of ditching +=, the only thing I can think of would be to make scalar+=val identical to (( scalar+=val )) but I think it would be a pity to lose the appending to scalars functionality. Does anyone else have any view or ideas? > type, is going too far. I think the suggested change for -= would be > even more confusing. The results might not be imediately obvious after a mix of both the math and non-math += for scalars but considered on their own I don't find them "confusing". > And the following can't be anything but a bug: A bug maybe, but it has bugger all to do with the += code. > (Previously meaning 4.0.4 but 4.1.0-dev-1 behaves as now so the problem will have been introduced sometime before that. 15292 at a guess as that is the one in that time frame dealing with math.c. Oliver __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com