Re: Proof of concept: "static" parameter scope

[Oliver Kiddle <okiddle@yahoo.co.uk>]

Bart wrote:
> 
> The patch below creates a module "zsh/param/static" which supports a
> single builtin command "static".  The included doc section describes
> "static" in detail, but briefly, it works like the "local" builtin
> except that variables so declared are not dynamically visible to any
> called functions.

Very nice.

> "Called functions" includes recursive calls to the function itself, so
> this doesn't work like C "static".  Therefore I'm in the market for a
> better name.

The trouble with "static" is that people with a C or C++ background will
expect something different. It might be better to find a new word in the
thesaurus that doesn't carry the baggage of another common meaning. Note
that, as you mention in the documentation patch, ksh93 has a typeset
-S option which does do C like static variables. Aside from confusing
users, the Zsh use of the term "parameter" seems even more tenuous when
applied to lexically scoped variables because they can't be used as
named parameters. So instead of "static" I would simply suggest "var".

This name does take the emphasis away from the scope but that could be a
good thing in terms of encouraging it's use. It is actually "local" with its
obscure dynamic scoping that really needs the more elaborate explanation
in the documentation. And "typeset" isn't a good name because
typesetting evokes things like LaTeX.

We might also want to hold on to -S for real static variables or perhaps
file backed "shared" variables (as someone recently requested).

> There are some tricks played to avoid creating new PM_* flag bits.  If
> this ceased to be a module and became a "real" builtin (something about
> which I'm ambivalent) there are parts that could be simplified by using
> another flag bit.

I like the fact that this hasn't added a load of extra complexity to
bin_typeset(). An extra flag wouldn't be too invasive if it helps the
implementation. I can't think of a reason to suggest that it should
cease to be a module if the implementation hasn't required it. It's also
worth having the reserved word form as per your later patch even if it
compromises the purity of the module separation.

Despite throwing quite a few odd things at it, I've not been able to
break it.

It'd be nice if typeset -p could tell you that it is a static variable.
Theres also ${(t)...}.

> +Although var(name)tt(=)var(value) sytax may be used in the argument list

typo: syntax

> +itemiz(An exported static remains in the environment of inner scopes but
> +appears unset for the current shell in those scopes.)
> +enditemize()

That doesn't seem ideal. It also seems that can be further affected if
the variable is declared local in some inner scope.

Oliver