Favorite non-python language trick?

[Mike Meyer]

"Shai" <shai at platonix.com> writes:

> They're called "Special vars", and you need to define them (unlike
> local LISP variables, which behave essentially like Python vars), but
> then you use them just like other vars (that is, you usually bind them
> with LET). This is the first I hear about them being ill-considered in
> LISP; http://www.gigamonkeys.com/book/ is a recently published LISP
> book which recommends them. I don't know about Scheme, but I think it
> does have them.

I'm pretty sure scheme doesn't have dynamically bound variables. I
just went through r5rs to check, and couldn't find them.

> dynamic x=10
> def bar():
>   print x
>
> I specified the syntax as I did, specifically to make it match the
> current definition of globals, which "enjoys" the same problems you
> noted with my dynamics.

This looks different from what I understood before. You're now
declaring the variable dynamic in the global scope, rather than in the
function that makes it dynamic. This is a *much* more palatable
situation.

Globals are lexically scoped. As such, you can find the defintion of
the variable by examining the module that includes the function. Yes,
other modules can reach into your module and change them - but you can
find those, because they reference your module by name.

A dynamic variable declared so in a function has no such clue
associated with it. If the variable is declared dynamic in the module
of the enclosed function, that provides a contextual clue.

Of course, you can do pretty much anything you want if you're willing
to grovel over the guts of the environment enough, but some things
shouldn't be easy.

> While I didn't write it explicitly, if both LISP and Python globals are
> to be followed, the dynamic x should somehow be defined in the scope of
> its module. On second thought, this means "dynamic" _must_ be added in
> the variable definition, for foo.foogle will simply access it as
> "othermodule.x", which doesn't differentiate globals from dynamics.
>
> Either way, Python as it is now allows foo.foogle to change x even
> without dynamic variables; it is accessible as barmodule.x. bar()
> should expect to have other functions mess with its globals, and
> dynamics are no different.

The question is, how hard is it to find the other people who are
messing with bar()'s globals? Normal usage with the current situation
makes it fairly starightforward. How does adding dynamicly bound
variables change this?

Of course, if you add the requirement that the variable be tagged in
the scope of the module, you're making things a lot better. That way,
readers of the module know that they need to look back along the call
chain for functions that use such variables. That makes them much
saner to find.

>> Instead of dynamic meaning "all references to the named variable(s)
>> will be dynamic until this function exits", have it mean "the named
>> variable(s) will be dynamic in this function." Whether it should only
>> check local variables in the calling routines, check local + global,
>> or check for all free variables, is an open question.
>>
>> I.e. - your example would be written:
>>
>> x = 10
>> def foo():
>>     dynamic x
>>     print x
>>
>> def bar():
>>     x = 11
>>     foo()
>>
>> def baz():
>>     bar()       # prints 11
>>     foo()       # Possibly an error?
>>
>
> This introduces the same problem you noted with my original proposal,
> but in reverse: Now, in bar(), you define and use a local variable, and
> suddenly some library function changes its behavior misteriously.

True. That pretty much kills my proposal.

      <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.