Re: named references

[Oliver Kiddle <opk@xxxxxxxxxxxxx>]

On 30 Jun, Bart Schaefer wrote:

> We should emulate ksh when `name' is already a nameref.
> However, we could follow our usual pattern of choosing some other syntax
> that's illegal in sh/ksh and giving it additional semantics; e.g.

Okay, that sounds good though I'll get the basics working first before
any new for syntax.

> > > } what should ${(t)ref} return - the same as what it refers to with
> > > } -nameref- inserted?

> Hmm, that's probably true.  In which case I'm not even sure if it should
> insert -nameref- anywhere.  Hard to say.

I know what you mean. My thinking behind inserting -nameref- was that
it would enable shell code to detect namerefs -- so for example I can
write a proper completion for unset -n -- while being compatible with
any old shell code that pattern matches against the output of ${(t)ref}
(which most probably does).

> > In 5068, you said that ksh has "separate namespaces for namerefs and
> > parameters". Can you remember what you meant by that?
> 
> Exactly what you mentioned before -- `nameref ref=var; typeset ref'
> doesn't output anything, and `unset ref' doesn't remove `ref', so the
> name `ref' does not behave like a parameter name.  What I didn't realize
> at the time was that `unset ref' actually removes `var', nor that there

The name `ref' does behave like a parameter name in ksh. `typeset ref' is just
defining ref if it isn't already defined so it will never output anything for
any variable in ksh. You have to do `typeset|grep ref'.

> was such a thing as `unset -n'.  (Flags to `unset'?  Heresy!)

Well, we already have two flags to unset -- -f and -m (and I've just realised
that I've not done a completion for them).

Anyway, I had a little time on the weekend to look at using a pointer for the
nameref. I am convinced that it is the better way, it'll just be slightly less
easy because I have to meddle more with existing code. The first problem is that
fetchvalue() currently returns NULL for PM_UNSET variables which I'm probably
going to have to change.

In case anyone is interested, attached is a descripton of ksh93 features which
aren't in zsh. Let me know if you know of things to add to it.

Oliver

local variables
---------------

The two function definition syntaxes work differently in ksh. function name
syntax is equivalent to using localtraps and typeset defines local variables.
function() syntax uses the same environment as the caller and shares all traps
and variables. This is also the case if the function is invoked with the `.'
special builtin.

Also note that in ksh, local variables are statically scoped (they aren't in
zsh). Dynamic scoping seems more natural for a shell in my opinion. In future
we could have something like Perl's `my' for static scoping (but preferably
using a less cheesy name).

discipline functions
--------------------

Any function with a "." in its name is a "discipline function". Anything up to
the last "." refers to a parameter. Only `get', `set' and `unset' are defined
at the moment and they intercept assignments to the variable.  The trouble is
that functions are not scoped so discipline functions can only be used for
global variables. The situation is actually that if you redefine a discipline
in a function for a local, the discipline is removed after the function returns
and ksh seg faults next time you access the variable because it is pointing to
a removed discipline. I pointed this out to David Korn and he got back to me so
it'll be fixed. Anyway, if anyone thinks about implementing discipline
functions, they might want to consider scoped functions first (in case it isn't
clear, ksh does *not* do scoped functions).

hierarchical variables
----------------------

If namerefs are the equivalent of pointers, these are the equivalent of
structs/records. They, amount to little more than allowing "." in a variable
name with nameref logic so `nameref ref=val; echo ${ref.one}' will output the
value of ${val.one}. There is also a compound assignment statement though so
you can do things like val=(one=1 two=2) instead of val.one=1;val.two=2

There are aspects of this which I don't like though: 
    $ n.o=1
    ksh: n.o=1: no parent
    $ n=
    $ n.o=1
    $ unset n # this unsets just `n' so we now have an orphaned ${n.o}
There is seemingly no way to manipulate a whole hierarchy such as to unset it
or whatever. The idea is that you pass it around by name which is fair enough.

namespaces
----------
I may have confused these with hierarchical variables previously. I get the
impression that these did not exist in the original ksh93 (the latest is
sub-release l). I also suspect that they are not quite finshed yet - I have had
a couple of seg faults and there is no documentation.

Anyway, there is a reserved word, `namespace' which I am guessing is similar to
Pascal's with statement. It seems to be possible to use it like this:
    $ .Z=
    $ .Z.one=hello
    $ namespace Z {
    > echo $one
    > }

set and typeset will then not list variables in the namespace. typeset will
include `namespace Z' in its output though.

These would be nice for hiding the completion system caches out of the way.

nested assignment statements
----------------------------

This is related to hierarchical variables above. Basically, any assignment of
the form var=( ... ) contains other assignment statements within the brackets.

So you can do stuff like:
rec=(integer i=3; arr=(one two three); assoc=([a]=1 [b]=2))

other misc things
-----------------
named references - of course

+= assignment operator (appends to or arithmetic add).

a wrapper (/etc/suid_exec) to allow suid/sgid/unreadable scripts to be run

/dev/fd/n emulated in the script argument to ksh

filenames of the form /dev/{tcp,udp}/hostid/port can be used to create tcp and
udp connections.

two consecutive characters in IFS has a different meaning