From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1212 invoked from network); 15 Nov 1998 16:11:47 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 15 Nov 1998 16:11:47 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id LAA27879; Sun, 15 Nov 1998 11:10:36 -0500 (EST) Resent-Date: Sun, 15 Nov 1998 11:10:36 -0500 (EST) Message-Id: <9811151554.AA19785@ibmth.df.unipi.it> To: zsh-workers@math.gatech.edu (Zsh hackers list) Subject: Re: Associative arrays and memory In-Reply-To: ""Bart Schaefer""'s message of "Sat, 14 Nov 1998 10:47:19 NFT." <981114104719.ZM22940@candle.brasslantern.com> Date: Sun, 15 Nov 1998 16:54:00 +0100 From: Peter Stephenson Resent-Message-ID: <"UOVWR1.0.Yp6.yplJs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4639 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu "Bart Schaefer" wrote: > 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. OK, I missed this point, then you're stuck with something of the complexity of what you had if you want to restore it. But what's wrong with making the associative array special? It could do some sort of dispatch based on the values of the hash it stored. Then you could get away with doing only a shallow save of the assoc array at this point (but see below), i.e. pretty much like what happens with other special parameters. Possibly in practice the parent AA will have to be marked as special, even if its own functionality is as normal. The alternatives to that are (1) check all non-special AA's for special contents at the point in question, which probably isn't on (2) the elements of the AA stop being special, which is a bit counterintuitive. > 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. That's true if the assoc array is not special, but its elements are. If the AA is itself special, it retains that behaviour on set/restore. Consider PATH=foo:bar builtin_or_func --- here PATH still works the same way as always, just with special save/restore. Then assigning a scalar to zle would give some kind of error. > 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? If the bits of the AA are special, and you want to restore them, then as I said above it seems you'll need the full complexity of the copyarams() mechanism because you can't guarantee restoring the state otherwise. Should it work? Probably yes. At some stage we will want whole assoc array assignments like 'hash2=$hash1', which presumably requires something like copyparams() anyway. Maybe I'll just have to bit the bullet and check for memory leaks properly :-(. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56100 Pisa, Italy