[saurik]

This isn'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't. You should at least implement this with thread local storage, though, if you are going to do this.

[brandmeyer]

IMO, the most comprehensive solution to this mechanism is provided in Racket scheme's parameterize system. Racket's parameters are about as safe as global variables can get. https://docs.racket-lang.org/guide/parameterize.html

What value does a forked thread get? The value at the dynamic scope of the parent at the point of thread creation.

What happens if a delimited continuation is invoked by a different thread compared to the one that created the continuation? If a parameterize call was made within the continuation's delimited extent, then it moves with the continuation. If not, it'll be in the executing thread. In either case the answer is consistent: The value within the dynamic extent of the continuation is used.

What happens to other threads if one overrides a parameter within its own dynamic scope? Nothing, threads don't have a dynamic scope relationship between them after thread creation.

[soegaard]

I agree that Racket parameters work very well.

FWIW the Racket parameters are inspired by:

"Processes vs. User-Level Threads in SCSH" by Martin Gasbichler and Michael Sperber

https://www.researchgate.net/publication/2546137_Processes_v...

[jolmg]

I think best practice among languages that support dynamic scoping is to only make use of it for global variables. As I understand it, one should only read or shadow, not modify, these variables. Since that's the case, besides the thread issue you mentioned, I'm not sure this solution is lacking. I don't know much C++, though, so I might be missing something.

[catern]

If you have multiple threads which try to bind the dynamically scoped variable to a new value, that should work fine and result in different values for the variable in each thread.

In this implementation, the threads will corrupt the data structure and result in undefined behavior.

[masklinn]

> If you have multiple threads which try to bind the dynamically scoped variable to a new value, that should work fine and result in different values for the variable in each thread.

That would work with proper threadlocals. However with dynamic variables you'd also get this for different sub-thread stacks. Not all languages can expose that but languages with generators do e.g. in Python if you `yield` then the stack is suspended, this means a threadlocal you've changed would not be rolled back, but a dynamic variable (which Python does not have) would.

[jolmg]

Yes, that's why:

> besides the thread issue you mentioned

[AnimalMuppet]

OK, help me out here: If I'm only using it for global variables, what does the dynamic scoping do for me? Why not just use a normal global variable?

[tsimionescu]

Basically for the same reason you would prefer RAII to new/delete. You can easily forget to change the value of a global variable back to its old value, whereas dynamic variable bindings automatically revert to their old values after you leave the scope of their declarations.

[jolmg]

The problem with local variables is that you can then not call a function that uses them unless you define such variables. One shouldn't be forced to know of such variables before calling such a function, since then they'd hardly be different from regular arguments.

The difference with statically-scoped global variables is that you can't set them to different things in different threads, and you have to be careful to set it back to it's original value after you called the code you wanted.

In other words, it's the same difference as using environment variables vs configuration files for executables.

[AnimalMuppet]

If I ever saw anyone I worked with trying to do something like "setting a global variable to different things in different threads", I would have very strong words for them. If they didn't listen, I'd have even stronger words for their manager: "Fire this bozo immediately". In what sane world is that considered a good idea? Is there any way in which doing so via "dynamic scoping" makes it any less of a horrible idea?

I'm having trouble making sense of your first paragraph. Part of the point of local variables is that they're local. It doesn't matter whether the function you're calling uses them or not. If it uses something with the same name, it's their own copy, and you don't care whether they do or don't. If they want yours, you pass it in. What am I missing?

[jolmg]

> If I ever saw anyone I worked with trying to do something like "setting a global variable to different things in different threads", I would have very strong words for them.

Because global variables aren't used the same between the two types of languages. In lexically-scoped languages, it's bad practice overall to use global variables for anything except constants. In dynamically-scoped languages, they're used as an environment just like how environment variables are used among processes.

You asked why not use "normal" (statically-scoped) global variables, and I replied on the difference. That doesn't mean that I support using them like that in such languages.

Imagine environment variables didn't exist. A `su` command that modified the home directory in /etc/passwd for the duration of its subprocess to change it back when it dies would also seem pretty ugly for me. Indeed, if a language lacks dynamic scoping or environment variables didn't exist, the proper practice would be to pass the whole environment explicitly as arguments. That's what's typically done in statically-scoped languages, but it has the caveats I mentioned in this other comment:

https://news.ycombinator.com/item?id=24545180

> I'm having trouble making sense of your first paragraph.

Here's an example using Elisp:

  ; Turning off static-scoping
  (setq lexical-binding nil)

  ;; Bad practice

  (defun foo ()
    bar)

  (foo)
  ;=> Debugger entered--Lisp error: (void-variable bar)

  (let ((bar 3))
    (foo))
  ;=> 3

  ;; Good practice

  (defvar bar 2)

  (foo)
  ;=> 2

  (let ((bar 3))
    (foo))
  ;=> 3

[jolmg]

To add to what I said yesterday, focusing on this question:

> Is there any way in which doing so via "dynamic scoping" makes it any less of a horrible idea?

In both types of languages it's a horrible thing to set a global variable, because the modification is visible to all code that runs later. If you want to know what value a global variable would have in a function, you'd need to be aware of all code that executed before.

In lexically-scoped languages, you can only read or set a variable. If you forbid setting it, you can only read it. In dynamically-scoped languages you can not only read or set a variable, you can also shadow it. Shadowing is not as bad as setting, because the "modification" is scoped to a call. Because of that, it doesn't undergo changes across functions that don't have a caller/callee relationship (e.g. cousin functions in a call-graph), and I believe that's where the real devil in modifying global variables lies, in reading a variable that could have been modified by functions that don't have a clear relationship with the current one.

Having said that, shadowing has its place. It certainly can be misused like any other feature, but I'm just answering why it's less of a horrible idea, as you put it. Though, it certainly has its benefit with no equal. Not even Haskell's Reader typeclass, because of its static-typed nature, offers exactly the same ability to modify the behavior of any callee-descendant function, unforeseen by the author of the function you're calling.

It occurs to me that this is also similar to the ability in OOP to inherit from a class or module and overriding one of its methods, only that the change, instead of being scoped to the callee-descendants, is scoped to the other methods (and their callers) that use the overriden method.

[guenthert]

It is a bit sad that Lisp isn't taught universally anymore. It might not be the most popular language, but it offers a lot of concepts which are worthwhile studying.

Dynamically-scoped variables (more precisely: variables with global scope and dynamic extent) are one such wonderful thing. In languages which offer those, one might use one in a function to hold a state which isn't related to the primary task of that function, e.g. a stream reference to send debug information to. Sure, one could give that to the function as one of the arguments, but doing so will make the interface eventually unwieldy and carrying such state from function to function becomes a hassle. Alternatively, one could keep such state as class variable, but if it isn't directly related to the or a single class, that wouldn't be easily comprehend-able design either. Keeping such state in a plain global variable (with indefinite extent) restricts it to being a single value for all consumers.

There's always more than one way to solve a technical problem, but dynamically scoped variables are sometimes the easiest, most straight-forward and most flexible way to do so.

[_ZeD_]

just to be sure, can't this problem be handled in OOP with a "trivial" class (or object) field?

[zwieback]

Part of this is Lisp-only history, outside of old Lisp users dynamic scoping really has few friends although the somewhat similar environment variable mechanism is widespread and accepted: https://en.wikipedia.org/wiki/Scope_(computer_science)#Histo...

[fiddlerwoaroof]

Yeah, “12 factor apps” basically use dynamic scope for dependency injection. But, also, I believe the Reader typeclass in Haskell is basically equivalent to dynamic scope? Haskellers seem to use this and a lot of similar techniques (Free monads/mtl style) to work around the lack of dynamic scope :).

[Joker_vD]

Think about passing some ambient context around. In Go, you do it by sticking an additional "ctx context.Context" parameter in every single function that conceivably may use it directly or indirectly, i.e. may call some other function that may or may not use it.

And sometimes you need to set up a derived context for one function call, but continue to use the previous one in other calls:

    func Foo(ctx context.Context, ...) {
        Bar1(ctx, ...)
        derived := makeDerivedContext(ctx)
        Bar2(derived, ...)
        Bar3(ctx, ...)
        // ...
    }

It's not hard, but just extremely tedious, esp. if context is mostly utilized in the leaf functions, and the most of the rest of your code simply passes it around.

That's where dynamic scoping enters in.

[munificent]

> This isn't dynamic scoping; this is just a global variable with a stack of values.

This isn't a latte; this is just an espresso with steamed milk added to it. :)

What you describe basically is how dynamic scoping is mechanically implemented under the hood.

[masklinn]

> What you describe basically is how dynamic scoping is mechanically implemented under the hood.

It's certainly how that's commonly emulated but that can leak out e.g. CPython uses threadlocals for decimal contexts, but if you set a localcontext in a coroutine / generator and suspend that, the information leaks out.

I assume the same happens with gevent unless you `patch_thread()`, and even then that assumes `decimal` always deref's threadlocals from the python-level module rather than statically resolve them.

[dapids]

Description !== Implementation

[chrisseaton]

> This isn't dynamic scoping; this is just a global variable with a stack of values.

I don't know what you think dynamic scoping is? Because 'global variable with a stack of values' is what it is.

[saurik]

No, that's how it is implemented by a compiler; what makes dynamic scoping "scoping" is that it related to how the variables are lexically organized. It is like claiming you are adding "classes" to a language but then merely providing an object-orientation runtime library akin to like, the Objective-C C runtime. You actually could design a system of a bunch of macros in C to have something like classes, but the low-level mechanism is not that. If you wanted to build something that was dynamic scoping in C++ I would (for avoidance of doubt, this is not what I was saying in my original comment) use thread local storage with a global map (and put the name as a string or something, maybe as a C++2y string template parameter) so that you didn't have to define the variable in the global scope. Because what could dynamic scoping possibly mean if you are literally having to type the variable into the global scope?

You really are confusing the implementation of dynamic scoping with what dynamic scoping is: the entire point of having that term at all is to describe how the variables are scoped not how they are set. If you have to type the name of the variable into the global scope, then obviously it isn't dynamically scoped.

[chrisseaton]

> No, that's how it is implemented by a compiler

What do you think the call stack is?

The only difference between what you're thinking of and what I'm thinking of is you're row-based and I'm columnar-based. Why is that such an important difference?

[tlb]

Some implementations search up the stack for a binding. Which is slower, but works correctly with multithreading.

[kazinator]

The deep binding approach will not work correctly with multithreading any more correctly than shallow binding, if there is only one such stack, or any shared state whatsoever that is not atomically manipulated.

It will work if there is a spaghetti stack. So that is to say, each thread extends the dynamic environment with a newly allocated frame that points upward to the parent environment.

Each thread needs a thread-specific pointer to the top of its own dynamic environment chain.

[tlb]

What do you mean by a multithreaded runtime with only one stack?

[chrisseaton]

I'm not sure what you think is the important difference between these implementations?

'Dynamic binding' is an abstract concept. The abstract concept is a global variable with a stack of values. How you implement it and whether you share the call-stack instead of a separate stack is is up to you. It's still the same dynamic scoping.

[tlb]

Only one of them works with multiple threads. Dynamic scoping based on save-and-restore of symbol value slots is completely incompatible with multithreading. That's why Emacs still doesn't have threads.

[kazinator]

Thread awareness is not a required part of the description of dynamic scoping.

Thread local storage does not make it absolutely re-entrant.

We could move the True Scotsman goalposts even farther out and say that we appreciate that the syntax being fine, but your approach doesn't work with interrupt handlers.

[saurik]

The syntax sort of looks the same but it isn't the same or "fine" if what you want is "dynamic scoping" (as dynamic scoping clearly is a way to scope things, not a way to set things). Is "thread local storage" the same as "state threading"? No. Does it look vaguely similar? Sure. Is "function argument binding" the same as "currying"? No. Could you imagine the former providing many of the benefits of the latter, or being how you might implement it? I guess?

I mentioned thread-local storage just because if you are going to develop this you should take that into consideration, as that's a common thing that will burn a lot of people; it was an unrelated code quality point for something you should do if you are going to do this kind of global variable stack thing. You could though use it to build something that was actually scoped by having a generic global dictionary and then keeping the names inside of the functions; at least then you are providing the core base noun of "dynamic scoping".

(And of course, as someone who has spent all of their time programming in C++ coroutines for over a year now, I am well aware that the thread local storage isn't sufficient to make this trick work correctly in every case.)