global in nested functions (viper)

[Tim Peters]

[John Skaller]
> The following file and viperi run demonstrate the current handling
> of the globals statement in viper.  What happens is: global causes
> a variable to refer to the containing context, often a module,
> but in this demo, there is also a nested function, global then refers
> to the locals() of the containing function, unless the variable
> is _also_ declared 'global' in that function.
>
> This behavious is not strictly python compatible, but will only
> cause problems in nested functions.
>
> Any comments?

Pretty slick!

It's unclear whether you intend that "global" is also needed for mere read
access to a containing scope's locals (I hope not; else e.g. a nested
recursive function would need to declare its own name "global", and that's
ugly; note that *not* requiring "global" for up-level references is also not
strictly Python-compatible).

Other than that uncertainly, the semantics seem fine.  The spelling is
unfortunate, since "global" doesn't mean "non-local" without heavy
squinting.  Go nuts <wink>, and make up a new keyword.  Then "global" could
retain its Python meaning, and the common uses of "global" for e.g.
accessing module-level instrumentation counters would continue to work fine
without needing to redeclare them at each intervening scope.  Even in the
land of the unboundedly nested, the outermost level is distinguished, so
deserves a shortcut.

> Viperi 2.0.1
> Copyright Maxtal P/L, John Skaller, Australia, 1999

Wow!  You're already 0.4.9 releases ahead of CPython <wink>.

or-maybe-viperi's-version-numbers-decrease-ly y'rs  - tim