Re: Proof of concept: "static" parameter scope

[Bart Schaefer <schaefer@brasslantern.com>]

Rearranging a bit ...

On Sep 28,  7:04pm, Oliver Kiddle wrote:
}
} Despite throwing quite a few odd things at it, I've not been able to
} break it.

I tried to make Test/V10* pretty comprehensive.

} It'd be nice if typeset -p could tell you that it is a static variable.

Cf. previous discussion about printparamnode(), which as it stands has
always gotten "local" wrong as well.  Or more accurately, given that
"typeset" is equivalent to "local" when called in function scope, it
is "typeset" of globals that "typeset -p" has always gotten wrong.

} Theres also ${(t)...}.

Yes, this could also be fixed with an actual flag bit -- or by adding
another callback to the gsu structure, which could also potentially be
used to fix printparamnode(), but is a fairly large change.

} > +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.

Agreed, and the best way to handle it would be that statics can't be
exported, but since variables can be declared and exported in two
independent steps, I didn't want to meddle that deeply with "export".

At that point though, I hadn't had the idea of swapping out the actual
handler in the builtintab ... but I really think that particular hack
is to be strongly discouraged.

} It also seems that can be further affected if
} the variable is declared local in some inner scope.

Indeed, nothing prevents creating a local with the same name as a static
as long as the scope is not the same, and exported locals behave as they
always did.

As for naming ...

On Sep 28,  7:04pm, Oliver Kiddle wrote:
}
} 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.

On Sep 28,  9:42pm, Mikael Magnusson wrote:
} 
} Also, "static" already means at least 3 different things in C, it
} doesn't make any sense to expect it to mean any particular one of
} these things in zsh?

The meaning in this zsh case is obviously "not dynamic" (because all
other variables except the positional parameters have dynamic scope).
C/C++ "static" encompasses both scoping and memory management semantics
and is mostly derived from the latter.

On Sep 28,  7:04pm, Oliver Kiddle wrote:
}
} [...]  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".

Possibly OK for a keyword, not so good for the name of a module.  One
ought to be able to get some idea of what's going to happen when the
module is loaded; "zsh/param/var" gives no hint, and looks redundant.

On Sep 28,  7:58pm, Roman Neuhauser wrote:
} Subject: Re: Proof of concept: "static" parameter scope
}
} one nitpick: "var" has no semantics regarding scope, which is not a
} problem per se, but with 'local' doing something (naively) unexpected,
} maybe a stronger signal would be in order?
} 
} i'd maybe suggest "private" instead, but the sweet succintness of "var"
} is really attractive.  hmm, what about "my"?

This is sort of like perl "my" but perl syntax lends itself to that as
a keyword a little better; "my -slew-of-option-letters thing" doesn't
roll so well and "zsh/param/my" is only a little better than "var".

On Sep 28,  9:42pm, Mikael Magnusson wrote:
} 
} What about "private" instead of static though? If the intention is to
} hide it from called functions, it is somewhat closer to that concept,
} if not just the normal word.

Once again it's not the same as C++ "private" if that's a concern, but
I do lean in this direction.

Make up a completely new term?  "limited" ?  "bounded" ?  "scoped" ?