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

[Oliver Kiddle <opk@xxxxxxx>]

Bart Schaefer wrote:
> When a reference is created, it's necessary to determine the scope in

I've run some tests and this looks good. The main issue I noticed was
with a reference to associative array elements.

  typeset -A assoc
  typeset -n ref=assoc[other]
  ref=val

This does work if assoc is assigned an initial value.

The error message from, e.g. `typeset -Z2 ref` is "can't change type
of a named reference". However, this is normally an attempt to change
the type of the target of a reference (-n is not specified). It works
fine for a scalar. So perhaps the error message should complain about
changing the type of [associative] array elements instead.

One ksh feature which this doesn't cover is the special behaviour in ksh
that `typeset -n ref=$1` will use the calling function scope to resolve
the target. This is necessary with the lexical (private) scoping of
ksh93 functions. The positional parameters are special-cased which I
find rather ugly. You could overload -u or -U for indicating Tcl-like
uplevel. The trouble with uplevel is that a called function can't know
how many levels up to specify if people are allowed to write wrappers.
I think a better solution is to take some syntax that isn't a valid
variable name. e.g typeset -n ref=\&1 Repeated use of an initial & would
indicate where another level of scope should be ascended. Wrapper
functions then don't need their own nameref and can just pass, e.g.
\&var as the variable parameter.

> One difference from ksh93 is that you can't convert scalars into
> namerefs, e.g., both with this and in ksh93:

That seems reasonable enough.

> Named references can't have any other attributes, and attempting to
> add an attribute to a named reference generates a warning.  However,

I can't see an actual conflict in permitting -r, making the reference
readonly not the target variable.

> With respect to zsh/param/private parameters, it's presently
> prohibited to have a "public" reference to a private parameter.  It
> might be possible to change this if someone can think of a use case.

To a user it would seem like a fairly arbitrary restriction.

Coming back to the uplevel question, for private to be more useful it'd
be really great to be able to have a private reference to a private
variable from the calling function scope. I'm not sure how easy that
even is with the current implementation of private.

> There is one glitch: if the reference is created before the parameter
> is declared private, and the private local is NOT hiding something in
> an outer scope, then the reference does not retroactively generate an
> error and assignments to the reference are silent no-ops.

Not sure I follow. Sounds like something that ought to be fixed.

> I also removed "kz" from TYPESET_OPTSTR in zsh.h -- as far as I can
> tell they should never have been there in the first place.

typeset -fu is like autoload. I think it was intentional.

Note that recent bash also has namerefs so should perhaps be compared.
They only resolve in local scope and don't include the local level with
the reference.

Oliver

PS. The basic approach is much the same as that which was rejected many
years back with consensus at that time being that a C pointer reference
should be used. I did make a start at the time using reference counting
but real life stuff got in the way and it was never completed. Zsh's
code does a lot of deleting and recreating parameter structures which is
problematic with that approach. I do still have an old patch that last
got rebased as recently as only 7 years ago if you're interested. Aside
from not working with array subscripts, I think I also concluded that it
wouldn't work for private variables because of their somewhat too clever
implementation.