11–20 of 64 posts
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?
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.
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.
Earlier quoted context omitted.
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.
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?
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.
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. Practically, dynamic scoping is more confusing than context objects. void main() { int x = 2; fn(); } Does fn access or change x? You need to inspect the body of fn to know. I would call dynamic scoping a poor form of coupling. Instead of bundling your coupling wir…
> 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. It's the same difference as using environment variables vs command line arguments. Imagine all programs having to pass TERM, DISPLAY, HOME, etc. as arguments in case some descendant process wants to use it and the user override. Like passing TERM, DISPLAY to git…
Earlier quoted context omitted.
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?
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…
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?
Earlier quoted context omitted.
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…
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?…
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))
;=> 3Earlier quoted context omitted.
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.
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?
Earlier quoted context omitted.
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…
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?…
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.