From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29042 invoked from network); 14 Nov 1998 18:50:18 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 14 Nov 1998 18:50:18 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id NAA13235; Sat, 14 Nov 1998 13:48:56 -0500 (EST) Resent-Date: Sat, 14 Nov 1998 13:48:56 -0500 (EST) From: "Bart Schaefer" Message-Id: <981114104719.ZM22940@candle.brasslantern.com> Date: Sat, 14 Nov 1998 10:47:19 -0800 In-Reply-To: <9811141526.AA19988@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "Re: Associative arrays and memory" (Nov 14, 4:26pm) References: <9811141526.AA19988@ibmth.df.unipi.it> X-Mailer: Z-Mail (4.0b.820 20aug96) To: Peter Stephenson , zsh-workers@math.gatech.edu (Zsh hackers list) Subject: Re: Associative arrays and memory MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"WFYsE2.0.hE3.O2TJs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4634 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Nov 14, 4:26pm, Peter Stephenson wrote: } Subject: Re: Associative arrays and memory } } "Bart Schaefer" wrote: } > zagzig<17> HISTSIZE=1000 } > zagzig<18> HISTSIZE=0 echo hello } > hello } > zagzig<19> echo $HISTSIZE } > 2 } } This seems to be OK after restoring the old behaviour, so I haven't } look further into what had gone wrong. I found it ... the assignment "pm = tpm;" was mistakenly deleted from below the code that was replaced by the call to copyparam(). That is, in save_params() in exec.c, it should look like tpm->nam = s; copyparam(tpm, pm); pm = tpm; So copyparam() itself is OK. } > } There are currently no special assoc arrays, of course, and it should } > } probably be possible to prevent there being any } > } > What about the discussion that started all this -- using an associative } > array to give user access to shell-internal completion data? } } Rats, I just looked at zle_params.c and you're right --- they're } marked special. Of course, a non-special associative array can contain special parameters. That was part of the idea of using a parameter hash as the implementation. And that would be the way to do it, rather than make the associative array itself special. } That doesn't mean assoc arrays need to be the same, though. The case } that needs worrying about is the following: } } hash=(?...?) builtin_or_func } } where the ?...? represents whatever we pick for whole array } assignments. It doesn't matter that a whole array is being assigned to the hash, does it? Even creating a scalar with the same parameter name would require that it be saved/restored. Or are you talking *about* special parameters within the associative array that need to be saved, and that's why whole-array assignment would matter? } There's also no problem if the hash is simply used for storing } information and is not tied to special variables or functions. You } only need a special mechanism for restoration for something like } $path, where there's an internal variable that needs setting; simply } restoring the struct param won't do that. That is, you need to call the pm->sets functions when restoring specials, which is what restore_params() does. But my implementation does not call anything equivalent to restore_params() on the parameter table stored in the association, so it isn't helping to have save_params() copy it in the first place. } If we can agree that use of } assoc arrays is simply going to be by direct access to the parameter } we can avoid ever copying it: the above shell pseudocode simply makes } the supplied $hash available for the duration of builtin_func. I'm not entirely sure what you mean about "direct access." If we're going to put stuff like the present $BUFFER into an association, it needs to be the case that assignment to (say) zle[BUFFER] actually modifies the line editor state. So the question is, should it ever be the case that zle=(? BUFFER "this is the command line" ... ?) builtin_or_func causes the old command line to be restored following builtin_or_func? And if we save and restore such a hash by the simple stacking method, is $zle[BUFFER] going to give the right thing after builtin_or_func? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com