From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2789 invoked from network); 28 Jun 2001 09:39:57 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 28 Jun 2001 09:39:57 -0000 Received: (qmail 20633 invoked by alias); 28 Jun 2001 09:39:04 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15158 Received: (qmail 20618 invoked from network); 28 Jun 2001 09:39:03 -0000 Message-ID: To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: named references In-reply-to: "Oliver Kiddle"'s message of "Wed, 27 Jun 2001 20:01:14 BST." <3B3A2D7A.7B8EA3AF@u.genie.co.uk> Date: Thu, 28 Jun 2001 10:39:21 +0100 From: Peter Stephenson Oliver Kiddle wrote: > Using a pointer for the reference is something I considered when I > started out. The problem is how to deal with references to unset > parameters. I'd be very tempted just to store the name of the object referred to, after a bit of sanity checking, and dereference it right at the last minute as if with ${(P)...} --- which I think is what you've got. This makes problems like this completely transparent, at the expense of a bit of speed which I don't think anybody is expecting out of namerefs. > Were you thinking of doing a parameter rewrite soon? Er, well, not exactly *soon*... > I'd be interested in more detail on the ideas you have for the > parameter code. What sort of thing might the interface provide? Thinking is the hard bit and I haven't really got that far. It's really just an abstraction of what we've got at the moment so that the surrounding code sees as few parameter functions as possible with, if possible, a single consistent set of flags etc. It needs to cover (off the top of my head): - creating local parameters; probably quite a lot of what's done directly in typeset at the moment can stay there - entering and leaving parameter scope - setting and reading parameters and it needs to do it in such a way that the surrounding code doesn't need to worry about the underlying parameter type. We can actually already do pretty much all of this --- for example, getsparam() will hide the parameter type and bundle it into a scalar --- but it's all done by ad hoc code at the next level down. I'd like to be able to do something like char *sret, **aret; Param param = paramtab->findparam(paramtab, ); param->get(param, FLAG_SCALAR, &sret); param->get(param, FLAG_ARRAY, &aret); --- not intended to be concrete, just an example of how it could be a bit neater. This particular example could do too much work, since it implies you can convert all types to all other types. But the source has been expanding faster than N**2 for ages now :-/. > > That would probably be a necessary prerequisite for > > any attempt at another ksh feature, the ability to tie getting and setting > > of parameters to shell functions. > > Do you mean something like ksh93 discipline functions. If we were to be > compatible with ksh93, I think that would also require ksh namespaces > (but I'm not sure). Yes, compatibility would imply both. > Would it be useful if I post a list of ksh93 features not in zsh? Feel free. -- Peter Stephenson Software Engineer CSR Ltd., Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. **********************************************************************