Re: values of associations pointed by P flag

["Bart Schaefer" <schaefer@brasslantern.com>]

On 5/25/06, Peter Stephenson <pws@csr.com> wrote:
>
> What I'd *really* like to be able to do is this:
>
>   sub() {
>       local foo
>
>       <treat_as_opaque_ref($1)>=what_I_want_to_set
>   }
>
>   fn() {
>     local foo
>
>     sub <generate_opaque_reference_to_my(foo)>
>   }

Of course in ksh "generate_opaque_reference_to_my(foo)" is

  nameref opaque=foo

which (if I understand it correctly, which I might not) acts roughly
like "local -h opaque" does in zsh in terms of scoping, but makes the
value of $opaque equivalent to the value of $foo and similarly causes
any assignments to opaque to be assigned through to foo.

> % print <generate_opaque_reference_to_my(foo)>
> #4351267a
>
> The opaque reference could be exactly that string, as long as we've got
> a way of turning it back internally a struct pm

That's an interesting suggestion for a way to impement namerefs.
Rather than really passing the reference around, which would require a
massive rewrite of the parameter code, return as the value a magic
string that gets processed "as if" with ${(P)...} at the critical
juncture.  The important bit is that such a string has to be
impossible to create by any other means, and has to encode how to
select both the paramscope and the parameter that are of interest.

> % foo=bar
> % ref=<generate_opaque_reference_to_my(foo)>
> % print $ref
> #4351267a:foo

See, this should never happen.  The parameter code should internally
recognize the magic value of $ref and replace it with (in this case)
"bar".  The trick may be in knowing at when to do the conversion.
Subscripts need to be applied to the referent, not to its value.  (We
have a bit of a complication in that plain arrays are subscriptable as
compound values even after the referent is lost, but hashes are not.)

> ... [foo goes out of scope] ...
> % print $<treat_as_opaque_ref($ref)>
> zsh: reference to variable "foo" no longer in scope

This would never happen with the scheme I describe, because the named
reference can never refer to a parameter at a "deeper" scope; that is,
foo and its opaque reference could go out of scope at the same time,
or the reference could go out of scope first, but foo could not go
first.

> However, that requires a complete list of all currently defined
> variables even if they're not currently in scope, and unfortunately in
> some cases we remove them temporarily from the parameter table.

If the reference can't "look down", then it only requires the current
state of the parameter table when creating one, right?  You can get to
wider scopes via existing references or through the current naming
scope, but you don't need to enumerate *all* variables.