Dynamic Scoping in C++

This isn&#x27;t dynamic scoping; this is just a global variable with a stack of values. I appreciate the syntax is sort of the same (though the * makes it different in a very important way) but the meaning isn&#x27;t. You should <i>at least</i> implement this with thread local storage, though, if you are going to do this.

This implementation will not work with C++20 coroutines.<p>With coroutines, implementing dynamic scope becomes a lot more interesting, because switching to different coroutines requires switching which dynamic bindings are active.<p>The correct implementation is somewhat subtle and not immediately obvious if you haven&#x27;t thought about it a lot. <a href="http:&#x2F;&#x2F;okmij.org&#x2F;ftp&#x2F;papers&#x2F;DDBinding.pdf" rel="nofollow">http:&#x2F;&#x2F;okmij.org&#x2F;ftp&#x2F;papers&#x2F;DDBinding.pdf</a> lays it out formally, but in the end the correct implementation is for each coroutine to have its own stack of dynamic bindings, and when you resume a coroutine in some context, you extend the bindings in that context with the coroutine&#x27;s set of bindings while the coroutine is running, and remove those bindings again when the coroutine is done running. This preserves the intuitive behavior that one expects from dynamic scope - see the paper for more justification.<p>Others have got this wrong too, so you&#x27;re in good company. Python, for example, added contextvars with <a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0567&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0567&#x2F;</a>, which have semantics which are <i>usually</i> identical to dynamic scope. But they chose an excessively-simple implementation, so the behavior diverges from proper dynamic scope when using coroutines in unusual ways, or using generators at all: <a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0568&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0568&#x2F;</a>

So, dynamic scoping are global variables... except with even way way way worse unpredictable behavior. Any function from three-level remote libraries can invisibly modify the meaning of code.<p>Sure, it allows for neat tricks, I suppose. It mostly allows impossible to diagnose error conditions since what happened actually depends on anything that may have happened before, invisibly.<p>I find it particularly amusing since fighting off global states has been a worthy goals of languages, libraries and framework. Without it, you can say goodbye to reproducible behavior and multi-threading.<p>(If dynamic scoping is thread-local, you still have the issue that anything can affect anything else, so nothing can be assumed to be reentrant anymore.)

I don’t see how this is functionally different to passing an object that contains references to the relate to variables; which I’ll call a context object.<p>Practically, dynamic scoping is more confusing than context objects.<p><pre><code> void main() { int x = 2; fn(); } </code></pre> Does fn access or change x? You need to inspect the body of fn to know.<p>I would call dynamic scoping a poor form of coupling. Instead of bundling your coupling wires in a neat little set of in&#x2F;out arguments and a return value (the format of which only needs the function’s declaration, not its definition), you are instead reaching out of and into the function’s body, like sprawling tendrils, as your function has free pickings of your variables.<p>It also strangely couples the names together. The outer function and the inner function may see the variable in completely different lights, yet dynamic scoping requires the outer use the name prescribed by the inner.<p>Optimization would be hard without WPO. You’d essentially need to keep a run-time “scope” object for every function. Though, the author’s proposed design for dynamic scoping in C++ means you don’t need it for every function; however that design has its own issues: how would you optimize such a design? It would a puzzling challenge.

I implemented exactly the same thing 20 years ago. It looked something like:<p><pre><code> Dynamic&lt;int&gt; foo; &#x2F;&#x2F; define at global scope { DynamicBind&lt;int&gt; foo; &#x2F;&#x2F; re-bind dynamically } </code></pre> It used thread-local storage and all. The global constructor for the Dynamic&lt;&gt; template class would allocate the thread specific key. The DynamicBind&lt;&gt; template class did the saving, location altering, and restoring.

Dynamic scoping moves a bunch of correctness checks from compile time to runtime. It basically introduces all the problems that come with shared mutable state across different functions&#x2F;methods. It becomes hard to reason about who mutates state where&#x2F;when.

Hi! Author of DynamicScope&lt;T&gt; here.<p>Regarding threads: It is correct that the current version of the template has a problem with multi-threaded programs. However, as adding &#x27;thread_local&#x27; to the global variable is sufficient to solve the problem, I did not mention this in the original post. However, I updated the blog post in this direction. Furthermore, I added a (run-time) check that ensures that you use DynamicScope&lt;T&gt; only with thread_local.<p>Regarding Lambdas: I don&#x27;t think there is a problem here. Dynamically scoped variables promise to return that value that is the most currenly bound in the current execution context. As the resolution is done on dereferencing, this is the exact behavior that DynamicScope&lt;T&gt; provides. This means that a lambda does not (lexically) catch the value of the dynamically-scope variable at definition time, but at the execution time of the lambda.

I&#x27;ve written enough GCL to know this can be god awful.

I never understood the advantages of dynamic scoping. It always seems to just boil down to a worse global or thread-local variable.<p>Is there a simple real-world example that would explain when dynamic scoping would be better than some kind of access protocol to a shared value?

I understand that it could be built with libraries in some languages, but I think it would be neat for a low-level language with ecosystem wide support for call-stack context objects.