From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6489 invoked from network); 18 Mar 2002 15:41:56 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 18 Mar 2002 15:41:56 -0000 Received: (qmail 23853 invoked by alias); 18 Mar 2002 15:41:49 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16855 Received: (qmail 23842 invoked from network); 18 Mar 2002 15:41:49 -0000 X-VirusChecked: Checked Date: Mon, 18 Mar 2002 15:41:19 +0000 From: Oliver Kiddle To: zsh-workers@sunsite.dk Subject: Re: special/readonly variables in sh emulation Message-ID: <20020318154119.GA11181@logica.com> References: <20020318125625.GA1787@logica.com> <27936.1016460462@csr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27936.1016460462@csr.com> User-Agent: Mutt/1.3.27i Sender: Oliver Kiddle Peter wrote: > I guess the problem is `load=yes' in zleparameter.mdd --- if it wasn't > always loaded there would be no problem. Is it just enough to set that > to `no' and make zle load it when it needs to run a widget? (If you're > using zle or completion widgets, all bets about compatibility are off.) > One way would be to track dependency information better. zsh/parameter > is loaded by default because zle needs it. zle itself is not used in a > non-interactive shell. So unless the user has directly registered an > interest in zsh/parameter we shouldn't load it until we need zle. >>From what I understand, zsh/parameter isn't loaded but we have the equivalent of zmodload -ap for all it's parameters done somewhere. I'm not sure that it is particularly connected to zle. We could limit this autoloading to interactive shells or skip it in sh emulation. As a short term solution and for 4.0, something like this is probably the best way to go and I think we should do it regardless of any longer term ideas like namespaces. Another thing to consider is that because the parameters in zsh/parameter are readonly, we could get the parameter autoloading to allow the parameter to be assigned to without loading the module and then be used - this would solve both the cases I mentioned. Only reading from the parameter without first assigning would do the autoload. > Another is to shift this sort of parameter into a namespace, as we've > been planning for a long time. I think Sven had a way of doing this > simply by allowing dots in parameter names --- it wasn't a fully > featured namespace implementation, but it might be close enough to allow The compound (hierarchical) parameters feature of ksh93 is exactly this - a hack to allow dots in a parameter name. I think this is a mistake because you lose the connection between parameters sharing a common parent. This means that you can't do things like unset a whole hierarchy by unsetting the parent. Some of these problems led on to the unfinished namespace idea in ksh93. Compound variables could be implemented better by being like associative arrays - the parent is a hash table of the elements the only difference being the elements can be any type, and the syntax is different. This alone wouldn't be hard to add onto the existing parameter code. It still needs further thought on my part but I think it would be possible to merge the concepts of namespaces and hierarchical variables by using lexical constructs to decide when to do things like copy-on-read for parent variables. > featured namespace implementation, but it might be close enough to allow > us to go over to that if anybody had the time to write it. Depends on what you mean by having time - in each day I don't have much free but if I start working on the parameter stuff, I'll get there eventually. So to start this off, if we start by getting together a list of: 1. what we think is wrong with the current implementation 2. what it has got right and should be preserved, 3. what new features we might want to support 4. any ideas for the implementation, in particular on the data structure and the interface. 5. anything else I'd prefer to get it right but if the consensus is in favour of something quicker and dirtier then fine. Also, am I right that we *need* a=() to assign an empty array? In ksh, this is how you define something as a compound variable parent which I'd prefer to have done with typeset. 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.