From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25358 invoked from network); 16 Nov 1998 13:08:38 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 16 Nov 1998 13:08:38 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id HAA13320; Mon, 16 Nov 1998 07:45:14 -0500 (EST) Resent-Date: Mon, 16 Nov 1998 07:45:14 -0500 (EST) From: "Bart Schaefer" Message-Id: <981116044345.ZM32703@candle.brasslantern.com> Date: Mon, 16 Nov 1998 04:43:45 -0800 In-Reply-To: <199811160954.KAA10377@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: Associative arrays and memory" (Nov 16, 10:54am) References: <199811160954.KAA10377@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (4.0b.820 20aug96) To: zsh-workers@math.gatech.edu Subject: Re: Associative arrays and memory MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"3OZH-2.0.3G3.Qv1Ks"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4649 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Nov 16, 10:54am, Sven Wischnowsky wrote: } Subject: Re: Associative arrays and memory } } (Every time I think about this I can't help remembering the discussion } about a new option system, am I the only one?) You are not. However, I thought the "new options system" mainly meant new syntax for "namespaces"? In which case it doesn't really help with any of these questions about special parameters. It could remove one level of indirection in the save/restore loops, I guess. } Two more things about assoc arrays: } } typeset -A foo } foo[hello]=world } echo $foo[(i)w*] } } gives `1', this should be `hello'. Yes, I wondered about this. (Does ksh93 have any equivalent syntax?) The problem at present is that $foo is the array of values, not of both values and keys. So for example: % bar=($foo) % echo $bar[$foo[(i)w*]] hello That would fail if $foo[(i)w*] substituted "hello" instead of "1". (Actually, there appears to be a bug in this code; the correct index is not always substituted. Patch hopefully to follow.) Then there are these examples: % echo ${(k)foo[@]} hello % echo ${(k)foo[(i)h*]} 1 % echo $foo[(kv)*] hello world % echo $foo[(kvi)w*] 2 } And if we use an assoc array for completion command name patterns we } would need pattern matching the other way round: the keys are taken as } patterns and `$funcs[(x)$cmdstr]' (for some value of `x') should give } the values of all entries whose key (taken as a pattern) match the } value of $cmdstr. But of course we could use a simple array for the } patterns and loop through it I was planning to add something using the hashtable pattern interface to take the input key as a pattern and return the values whose keys match, but I wasn't thinking of turning it inside out like that. I think the way I'd do the above would be the (equivalent of the) loop: for pat in ${(k)funcs[@]} do if [[ $cmdstr = $pat ]] then completions=($completions $funcs[$pat]) fi done The problem (with or without your magic [(x)...] syntax) is that an associative array is unordered, but presumably we want some fixed order to the interpretation of completions when multiple patterns match the command. (If we're using an associative array for completions, how do you implement the equivalent of the -tc option?) } (the question is: are there other uses } where such a feature might be interesting to have I think for a shell-script-level feature, this has gone over the edge of reasonable complexity. If perl doesn't have this feature, we should avoid it too. :-} } and: if we have a } way to get a list of matching entries, should we make this with a new } modifier flag that can be combined with `i', `I', `r', and `R' so that } all of them give a list, not only the first matching one?). Maybe it's because it's 4:30am, but I don't understand that part at all. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com