[PATCH 0/2] persistent locals (sort of)

[PATCH 0/2] persistent locals (sort of)

[Bart Schaefer]

This is an idea that was seeded by the zsh-users question from Budi
about "plain variable which is retaining its value all the time".
Diffs to follow in two parts:

Part 1:  There doesn't seem to be any reason a named reference should
not be declared "hideval" (-H).  This just means that if it gets
dumped out in a "typeset -p" output, you don't see what it refers to.
A minor drawback is that this is also what an undefined "placeholder"
named reference looks like.  This bit isn't essential to the scheme,
see below.

Part 2:  A new module zsh/param/persistent.  It introduces a builtin
"persistent" which acts like "local" except that when run again at the
next call to the function, it restores the value from the previous
call to the function (actually, to any function having the same name).
Any assignment made in the arguments to "persistent" is ignored, so
this looks very much like "static" in C, except that the name is
visible to nested scopes as usual.

This should probably be considered a proof of concept at the moment.
The way it actually works:

A namespace prefix is first generated based on the function name, so
if the function is "foo" the namespace is ".persistent_foo."  This
means it can only be used in functions that have names in the form of
simple identifiers; it'll produce an error if used outside a function
or in an anonymous function or in any function with dots, hyphens,
slashes, etc. in the name.  This could be solved with some kind of
function-name hashing, I suppose.

The argument list is then walked and split into name and value at "="
as with typeset.  Because this is a builtin, there can't be array
assignments etc., which is a second drawback.  Every name is prefixed
with the namespace and checked for existence; iff it doesn't yet exist
in the namespace, it's created with the specified value if any.
Finally, and always, all the original names are created as named
references to their counterpart in the namespace, using the hideval
option from Part 1.

The end result is that the calling function always has named
references to the same hidden global variables.  Only those references
are re-created on every re-entry.

A further change (or option) that could make this even more
"static"-like would be to create the named references using "private".
In fact I suppose this could even be merged into the "private" module.
I debated copying that module's hack for creating a keyword, but
decided against it.

Re: [PATCH 0/2] persistent locals (sort of)

[Bart Schaefer]

Attempted to send these far enough apart that the article number
sequence would match the subject number sequence, but oh well.

On Tue, Sep 5, 2023 at 10:04 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> The argument list is then walked and [...]  Every name is prefixed
> with the namespace and checked for existence; iff it doesn't yet exist
> in the namespace, it's created with the specified value if any.
> Finally, and always, all the original names are created as named
> references to their counterpart in the namespace, using the hideval
> option from Part 1.

I just noticed that the comment in Part 2 has this in the other order.
My thought was that if there were any problem creating the named
references, the namespace should not get populated, but when it came
to making it all work the other order was more natural.  Can anyone
think of a way it's likely to go wrong?  (Is anyone [else] interested
enough for me to bother?)