From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6369 invoked from network); 16 Jan 2002 14:44:01 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 16 Jan 2002 14:44:01 -0000 Received: (qmail 1966 invoked by alias); 16 Jan 2002 14:43:53 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16460 Received: (qmail 1953 invoked from network); 16 Jan 2002 14:43:50 -0000 Message-ID: <20020116144321.95331.qmail@web9303.mail.yahoo.com> Date: Wed, 16 Jan 2002 14:43:21 +0000 (GMT) From: =?iso-8859-1?q?Oliver=20Kiddle?= Subject: Re: PATCH: += parameter assignments To: Bart Schaefer , zsh-workers@sunsite.dk In-Reply-To: <1020114184715.ZM18893@candle.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Bart wrote: > } > 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. Yes, unless assignments outside (( )) were always scalar as I think they should be. > I'd actually forgotten about that effect of assignment to integers. Having remembered it, would you now agree that the current += behaviour of doing arithmetic for numerics is at least consistent with normal assignments? > } > 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. Convert it back to an integer with math evaluation resulting (for this example) in a bad math expression error. It wouldn't be much use and would allow some really nasty tricks to be done. My point being that assignments inside (( )) converting results back to a scalar is not a good idea in my opinion. > } 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. That's bad! Basically, I can't see a solution that only involves changes to += without either leaving inconsistencies with normal assignments or worse problems. In summary, I think the ideal would be to make all assignments depend on context only. So: ((a=5)) would always result in a being of integer type and a=5 would always result in a being of scalar type Any scalars used in integer context would still have to be converted to be numeric first and vice versa. Using typeset to declare a variable as an integer would only be useful if initialising the variable. The trouble with this is it would be a big incompatibility and of minimal use interactively. An option maybe? > That whole mailing list has been silent for a long time -- or at least True but the list probably still works. Unless I missed it, POSIX doesn't have assignments in arithmetic context or numeric variables. > 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.) Have you looked at it recently? The last time I looked, there was very little change to the shell spec, all the changes being in other areas. > Really? I'd say truncation was the reverse of appending. Well, at least sort of. Enough that with =+ not being an option, it seemed like a reasonable idea. I couldn't see us ever wanting -= for truncation as you can already use subscripts to do truncation (and %= would be more likely). I quite often do things like `fpath=(~+ $fpath)' so I thought it'd be useful (though I can use a subscript of [1,0]). 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