Re: [PATCH 1/3]: Add named references

[Oliver Kiddle <opk@xxxxxxx>]

On 9 Feb, Bart Schaefer wrote (I've reordered this):
> > This should be an error perhaps:
> >
> >   typeset -n ref=arr[1][2]
>
> Why?  ${ary[1][2]} isn't an error, it's the 2nd character of the first
> word in $ary.

Sorry, should have been clearer. Applying later subscripts is even
better than an error but the following is not ideal:

  % arr=( one two three )
  % typeset -n ref=arr[2][1]
  % echo $ref
  two[1]
  % ref=x
  % typeset -p arr
  typeset -a arr=( one x three )
  % echo $ref
  x[1]
  % typeset -n ref=arr[1]whatever
  % echo $ref
  onewhatever

> Yeah, I don't like the idea that a called function can arbitrarily
> grab parameters from its caller just by sticking & in front.  Caller
> needs to do do something (even if only make "normal" use of dynamic
> scope) to make the parameter "grabbable".

Allowing such things as uplevel statements (Tcl), special syntax, or
introspection modules (Python's inspect), is fairly normal for a
scripting language.

As I've mentioned, we already have the situation where the caller
needs nothing to make a private grabable by a builtin:
  private -a var
  compadd -O var one two three
And writing wrappers to e.g. compadd is useful.

But I don't think we need to address references to privates in other
scopes at this point before the other patches are even applied. May be
better to consider whether there are other advantages in moving private
to the main shell first as that may ease any implementation.

> > >   typeset -n ref
> > >   for ref in 'hash[(e)'${(k)^hash[(R)?*]}']'; do ...
> >
> > "just"!?
>
> Hah!  Point was that it's do-able without "for"-context-sensitive
> special subscript semantics.  I think it would be strange for

I can't think of a sensible way. Was just that it could be useful.
Best long term solution might be to allow arrays of references. Bash
does allow arrays of integers.

> The others would all have to be special-cased individually.  What is
> $+ ?  Do you mean $- ?

Yes.

Oliver