Oh, and by the way, here's my plan for handling "private" variables:
If it's a global that is supposed to be internal (used only by your module), I suggest prefixing it with a _, so foo would become _foo, etc. But still make it accessible to other modules, just in case.
Why? Well, consider the scenario where somebody imports your module but it has a bug in it. If the implementation is exposed, they can potentially fix the bug. Another problem is adding new features... if your module hides all of it's internal details, then it will probably be harder to extend your module.
Thus, I propose that internal variables are handled by an "honor" system, so to speak. The _ means that it is intended for internal use, so other modules shouldn't go mucking with it if they don't have to, but they still can, if they need to. It also means that the variable is not part of the official API, so it could change or be removed in future versions of the module.
In other words, don't depend on variables prefixed with _ and avoid mucking around with them if you can.
On the other hand, if the variable really truly is useful only for your module and nobody else (a gensym, maybe?) then it's okay to wrap it in a (let), that way only your module can see it.
Why? Well, consider the scenario where somebody imports your module but it has a bug in it.
We're practically the same person. XD That's one of the use cases I always reach for when talking about Penknife or about language hackability in general.
I still don't really like Python's "everything is open!" approach, but I appreciate it a bit more now than I used to. On the other hand, I do think it's a good fit for Arc.
