From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19188 invoked from network); 3 Apr 2002 14:57:53 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 3 Apr 2002 14:57:53 -0000 Received: (qmail 132 invoked by alias); 3 Apr 2002 14:57:48 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16932 Received: (qmail 119 invoked from network); 3 Apr 2002 14:57:47 -0000 X-VirusChecked: Checked From: Oliver Kiddle To: zsh-workers@sunsite.dk Subject: Re: special/readonly variables in sh emulation Date: Wed, 03 Apr 2002 15:57:17 +0100 Sender: kiddleo@logica.com Message-Id: Bart wrote: > > } Should we allow attributes like uppercase and integer to apply across > } an array like in ksh (this is messier for hashes as each element has > } its own param)? > > I don't know what the ksh implementation of this is like -- does it apply > the conversion at fetch time, or at assign time? Assign time it seems - fetch time would be better in my opinion. The ksh feature which I was refering to and which I like is: $ a=(one two three) $ typeset -u a $ echo ${a[@]} ONE TWO THREE And similarly for other typeset options such as -i. And thanks for answering the various questions. > The way I would structure this is: > > The lowest-level API provides functions to set and get scalars (strings, > ints, etc.), arrays, array elements, and associative array elements > (including getting the keys or values). > > An intermediate API provides functions implemented in terms of the above > to set and get string ranges, array slices, and arrays of associative > array elements. Special parameters have the option of implementing only > the lowest-level API and using the functions from the intermediate one, > or of providing the intermediate ones for efficiency or other effects. Ok, that is roughly what the patch I posted was heading towards though I'm entirely happy with it. To support the specials overriding the intermediate API you get a fairly big method table. Simple specials would use the default methods. Unless anyone can think of a better system than the method tables or come up with a better, more generic version of the paramdef struct system for setting up specials? > The complication arises when we add in nested substitutions, where the > result of an inner substitution has to be treated as a parameter value > for purposes of outer substitutions. I suggest we actually create a > dummy parameter in this case rather than trying to handle everything via > manipulation of the Value structure -- but that means some pretty heavy > rewriting of paramsubst() and getarg(). A dummy param might be good. I was sort of hoping to get rid of the value struct and use start/end ints where necessary but another option might be a dummy param there to. > If we did create a dummy parameter, we could even give it a name and > let the surrounding substitutions refer to it explicitly, e.g.: > > ... ${$(some command):+blah blah $_ blah blah} ... That's an interesting idea. > I haven't looked at your patch in detail yet, but these seems like things > that could go in the optional intermediate-level API. It would be useful if someone could look at it just a little bit. What I'm least sure of is what is needed to support associative specials properly. I've not done anything on this since last week - I was away for the Easter bank holidays. Oliver This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.