Re: All the way up or current scope

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, May 19, 2025 at 6:32 PM Philippe Altherr
<philippe.altherr@xxxxxxxxx> wrote:
>
> I really, really, would like that the upcoming release includes generalized upper references (see question 1).

I really, really would like the upcoming release to go out soon and
without any new more new inventions before a wider audience has been
exposed.

> - The main attribute of loose references is that ... the referred variable may change (even without exiting a scope).

I have yet to understand why that's desirable.  Named references
should act as nearly as possible "as if" they are a pointer to an
object.  (I feel like I've said this before.)  The differences should
only be those enforced by dynamic scoping, e.g., that a variable from
an outer scope can be assigned (or explicitly unset) from an inner
scope and that leaving the inner scope doesn't implicitly unset the
variable in the outer scope.  Declaring a new object should not
mystically replace the pointed-to object.  Deleting the pointed-to
object (by leaving its scope, in this case) is another matter ... once
you're in undefined territory, names and values mean more than
pointers and objects, in shell.

If you want a reference that makes no effort to emulate a pointer, you
have ${(P)name}.

> - The fundamental difference between my "upper" field and the existing "base" field is that the former is a property of the reference (it can be initialized when the reference is defined), while the latter is a property of the referent (it must be initialized when the reference is initialized).

I almost agree with this and it leads to an instructive analogy I
hadn't thought of before:  The memory address stored in a true pointer
is also a property of the referent.  However, the current use of
"base" is more than that -- it's a property of the scope of the
referent.

Nevertheless I am spending some time considering whether there are any
overlaps that make sense.

> It's this difference that opens the door to handling subscripts in the same way as the main variable. With the current implementation handling subscripts in the same way as the main variable would require the ability to store one "base" field for each variable that shows up in the computation of the subscript.

I don't see the distinction?  Aren't there only two possible scopes
involved here?  Either you evaluate the subscript relative to the
current scope (locallevel), or you evaluate it relative to the "base"
scope (currently impossible).  Everything else is just default dynamic
scope behavior.  What other scopes would it be necessary to record?

> - For my comparison with ksh, I assumed that we would like to be able to run as many ksh scripts as possible in normal Zsh, i.e., in Zsh without ksh emulation.

I'm not sure that's a reasonable goal.  For all but the simplest
scripts it's incompatible with running as many bash scripts as
possible, and so on.  There's a reason we have so many setopts and
ksh-style autoloading and the "emulate" command.  A better assumption
would be that we want to support idioms that a ksh programmer would
find familiar.

Taking your questions out of order:

> Question 2
>
> Do we need to support references to nested variables (in the upcoming release)?

I believe we'd prefer to.  Each of the K01 tests (prior to the ones I
adapted from your nr-test script) was introduced based on a discussion
on zsh-workers.  However, a significant use case not included in K01
is that same-shell command-substitutions are nested scopes:
  f() {
   local -n ref
   local var=${ local X=1 Y=2; for ref in X Y; do ... done }
  }

Obviously that particular example is contrived, but it seems
reasonable to want to factor out declarations that might be used in
multiple nested scopes.

> Question 1
>
> Can we add an optional integer argument to the -u option to support generalized upper scope references?

Modulo that first sentence of my reply, I'm not opposed, but I would
like some examples.