Re: Up-scope named references, vs. ksh

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Fri, Mar 1, 2024 at 10:22 AM Stephane Chazelas <stephane@xxxxxxxxxxxx> wrote:
>
> 2024-02-28 21:16:13 -0800, Bart Schaefer:
> > [...] The workaround in
> > underlying C code would be to have "typeset -n r1=a" (again your
> > example) implicitly create the global $a as early as possible.
> [...]
>
> Couldn't typeset -n ref=var, when it finds that var is not set
> create one in global scope with a "unset-but-referenced" flag

Yes, that's what I just said.

> and maybe a reference count associated with it

Reference counting ends up being a pretty significant refactoring of
the parameter code, we started down that path some time ago and didn't
get satisfactory results.

> Comparing with ksh93:

You really can't, because ksh93 uses static scoping of locals where
zsh uses dynamic scoping, and ksh also has special handling of
"typeset -n ref=$1" (and other positionals) that is simply never going
to happen in zsh.

The upshot is that if we go with implicitly creating a variable in
global scope, it doesn't solve the other reference issues -- so the
question is, when we document the pitfalls of using upward-pointing
named references, do we also break the dynamic scope paradigm for the
specific case of nonexistent globals?

> Imagine a function meant to create a variable whose name is passed as argument

That can't cause a serious difficulty because if you have such a
function, the caller must know that the argument is a parameter name,
and therefore must be able to create the parameter in the correct
scope in advance.  It's just not as syntactically sugary as ksh.

Note that all of these situations also exist with builtins like zstat
and even "print -v" that accept parameter names as arguments.