From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26302 invoked from network); 15 Jan 2002 17:55:13 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 15 Jan 2002 17:55:13 -0000 Received: (qmail 28164 invoked by alias); 15 Jan 2002 17:55:07 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16459 Received: (qmail 28148 invoked from network); 15 Jan 2002 17:55:06 -0000 From: "Bart Schaefer" Message-Id: <1020115175449.ZM20201@candle.brasslantern.com> Date: Tue, 15 Jan 2002 17:54:49 +0000 In-Reply-To: <20020115161603.46731.qmail@web9302.mail.yahoo.com> Comments: In reply to Oliver Kiddle "Re: PATCH: += parameter assignments" (Jan 15, 4:16pm) References: <20020115161603.46731.qmail@web9302.mail.yahoo.com> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.dk Subject: Re: PATCH: += parameter assignments MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jan 15, 4:16pm, Oliver Kiddle wrote: } Subject: Re: PATCH: += parameter assignments } } > On Jan 14, 12:45pm, Oliver Kiddle wrote: } } > The point is that I can't think of -anything- reasonable to expect, } > except perhaps that in a saner world ((s+=5)) would be an error } > because you can't add an integer to a string. Unfortunately we're } > beyond hope of changing that (and I wouldn't really want to anyway). } > } > About the closest thing I can come up with is that all assignments } > in (( )) should force the parameter type to change to numeric } > (integer or float), but that has its own set of potential gotchas. } } This would seem sensible to me but is it too late to be changing that? } If you think it is an option then can you elaborate on the "gotchas"? You pointed one of them out yourself: ((s+=5)) s=foo produces s=0, which could be surprising if `s' was previously a scalar. I'd actually forgotten about that effect of assignment to integers. } > Better might be if += outside of (( )) always converted numerics } > to strings and then did an append. } } This is perhaps worth considering. I did actually consider it at the } time but didn't do it because of ksh compatibility. To be consistent } with assignments inside (( )), it would have the convert the result of } the appending back to a numeric type afterwards (which would limit the } usefulness of it). It'd also be impossible; following integer s=5 s+=four how would one convert `5four' back to an integer? If the type were going to change to scalar, that change would have to stick. } But you can't look at s=foo and know what it is going to do because if } s is an integer, you end up with s being 0 (or whatever foo } arithmetically evaluates to). I think it would be better if this was a } scalar assignment but it isn't. I agree that would be better. A function that wants to create `s' as a global scalar probably *doesn't* have a `typeset -g s=' in it. If `s' already exists as an integer, strange things are going to happen. } My intention was to never in a script use: } numeric+=val using (( numeric+=val )) instead or, } array+=val using array+=( val ) instead } so nobody reading the script might be confused. } } Perhaps we could just make a recommendation in the manual that with } numeric variables assignments outside of (( )) not be used. I'm more concerned about people who intended to do exactly that but who mistakenly left out the parens, ending up with a script that works for a while and then mysteriously breaks. } Note that David Korn included += in his "first cut" for the new } standard (item 48. in 3 Aug e-mail) so it might be worth sending him an } e-mail about this. That whole mailing list has been silent for a long time -- or at least I haven't received any messages from it. (In a related note, Austin Group just got their spec through another hurdle and are accepting errata.) } > To have -= be additive for strings and "subtractive" for numeric } > types is just compounding the problem. } } That probably just depends on how you think about the operations. `+' } being used as an appending operation seems fairly logical to me without } thinking about it as being "additive". `-' is the reverse of `+' and } prepending the reverse of appending Really? I'd say truncation was the reverse of appending. Pop is the opposite of push; unshift is the opposite of shift, not of push. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net