Dynamic Scoping - Why?

Question

I've learned that static scoping is the only sane way to do things, and that dynamic scoping is the tool of the devil, and results only from poor implementations of interpreters/compilers.

Then I saw this snippet from a Common Lisp vs. Scheme article:

Both Lexically and Dynamically    Lexical scope only, per the standard.
scoped special vars.  Common      Dynamically scoped vars are provided
Lisp just wins on this point.     by some implementations as an extension
                                  but code using them is not portable.

     (I have heard the arguments about whether Dynamic scoping
      is or is not a Bad Idea in the first place.  I don't care. 
      I'm just noting that you can do things with it that you 
      can't easily do without it.)

Why does Common Lisp "just win on this point"? What things are easier to do with dynamic scoping? I really can't justify ever needing it / seeing it as a good thing.

Answer 1

Dynamic scoping is useful in some domain-specific languages. In particular, it can be handly in stylesheet languages. My experience is from the GNU TeXmacs stylesheet language.

In this language display parameters are stored in dynamically scoped variables. Those variables affect the rendering of every atom in their scope, including atoms that are produced by functions called in the scope.

Dynamic scoping in TeXmacs is also used, among other things, for labeling cross-references. Anchors used for cross references get their label from their environment. For example, an anchor included in a formula block will use the formula number as label, instead of the section number for an anchor located after the formula.

Come to think of it, unix environment variables are also dynamically scoped variables. Albeit inner scopes cannot alter the value of variables in outer scopes.

As Barry Kelly noted, dynamic scoping can also be useful to implement language features that care about the call scope, such as exception handling, or context-dependent permission handling. In the presence of continuations, scopes can be entered and exit without walking through the call stack.

Answer 2

The primary risk with dynamic scope is unintended consequences. Dynamic scoping makes scope follow the runtime stack, which means that the set of symbols in scope is much larger and far from obvious at the point of any symbol usage. Dynamically scoped variables are a lot like global variables, only there may be more than one version of each variable with only the latest definition visible, hiding all the others.

Dynamic scope, in so far as it is useful, it is useful for behaviour that needs to be sensitive to the runtime stack. For example (and speaking generally, not specific to Lisp or variants):

• exception handling - the top-most catch block is the one that is "in scope" when an exception occurs
• security - .NET code-based security makes decisions on the accessibility of certain privileged APIs based on what code called it.

The problem with relying on it for other uses is that it creates implicit dependencies and coupling between lexically distant pieces of code. In this way, it's also similar to global variables, only it can be worse (due to dynamically overridden definitions).

Answer 3

Like everything else, Dynamic Scoping is merely a tool. Used well it can make certain tasks easier. Used poorly it can introduce bugs and headaches.

I can certainly see some uses for it. One can eliminate the need to pass variables to some functions.

For instance, I might set the display up at the beginning of the program, and every graphic operation just assumes this display.

If I want to set up a window inside that display, then I can 'add' that window to the variable stack that otherwise specifies the display, and any graphic operations performed while in this state will go to the window rather than the display as a whole.

It's a contrived example that can be done equally well by passing parameters to functions, but when you look at some of the code this sort of task generates you realize that global variables are really a much easier way to go, and dynamic scoping gives you a lot of the sanity of global variables with the flexibility of function parameters.

Answer 4

Dynamic scope allows for definition of contextual functions. In that sense, it is quite similar to dependency injection in modern frameworks. (For example, consider when you annotate a Java class with dependency injection definitions to allow transparent initialization of various references. (cf spring, or JPA, etc.))

Obviously, dynamic scoping makes certain assumptions regarding the runtime characteristics of the invocation site for a given function which can not be guaranteed at compile (or design) time. Again, following the example of a modern (Java) framework component, if you instantiate such a class outside of the controlled (runtime) environment of a container, it is easily possible that the class will not be able to function given that its required dependencies will not have been initialized (aka injected).

But equally obviously, component systems (as just one example) clearly benefit from dynamic binding mechanisms. Dependency injection is a framework level means of achieving this. Dynamic scoping is a language level means of the same.

Answer 5

Dynamically scoped variables are a powerful, but also sometimes unintuive and dangerous tool.

Imagine you want to have thread specific global variables, i.e. every thread has its own set of global variables. This can easily be done with dynamic scope. Just change the references to this variables at thread initialization.

Or think about exceptions: they are dynamically scoped in most languages. If you had to build an exceptions system from scratch, you could easily do that with dynamically scoped variables.