why exactly do we want write access to outer scopes?
for completeness, to avoid the overhead of introducing a class here and there, to facilitate people using Scheme textbooks with Python?
I am currently working on implementing an algorithm with the following properties: - It is an algorithm, not a data structure; that is, you run it, it returns an answer, and it doesn't leave any persistent state afterwards. - It is sufficiently complex that I prefer to break it into several different functions or methods. - These functions or methods need to share various state variables.
If I implement it as a collection of separate functions, then there's a lot of unnecessary code complexity involved in passing the state variables from one function to the next, returning the changes to the variables, etc. Also, it doesn't present a modular interface to the rest of the project -- code outside this algorithm is not prevented from calling the internal subroutines of the algorithm.
If I implement it as a collection of methods of an object, I then have to include a separate function which creates an instance of the object and immediately destroys it. This seems clumsy and also doesn't fit with my intuition about what objects are for (representing persistent structure). Also, again, modularity is violated -- outside code should not be making instances of this object or accessing its methods.
What I would like to do is to make an outer function, which sets up the state variables, defines inner functions, and then calls those functions. Currently, this sort of works: most of the state variables consist of mutable objects, so I can mutate them without rebinding them. But some of the state is immutable (in this case, an int) so I need to somehow encapsulate it in mutable objects, which is again clumsy. Write access to outer scopes would let me avoid this encapsulation problem.