Re: special/readonly variables in sh emulation

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

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.