Re: named references

[Peter Stephenson <pws@csr.com>]

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, <however>);

  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 <pws@csr.com>                  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.
**********************************************************************