Live data from Hacker News

Dynamic Scoping in C++

blog.dokucode.de

61–64 of 64 posts

Re: Dynamic Scoping in C++

#61
post #57
post #51

Earlier quoted context omitted.

> 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 in case you want to override them for the configured pager or editor. Interestingly this is exactly what I have been wishing was standard practice for a few years now! Otherwise you end up pickup up implicit configuration from the environ…

> Interestingly this is exactly what I have been wishing was standard practice for a few years now! You mean that when you call e.g. `tmux` you want to be forced to call it as something like `tmux -e HOME=... -e TERM=... -e DISPLAY=... -e USER=... ...`, and likewise for basically all other programs? > I admit my years of experience with Haskell may have coloured this opinion. Reader in Haskell helps prevent having to…

On the command line, i.e. a human interface, I'd be willing to soften my stance a bit but any time a program calls another program, yes, I would like it to be explicit about the parameters it accepts.

> Reader in Haskell helps prevent having to do that similar to environment variables or dynamic scoping

I would be happy with an interface like Reader in Haskell but I don't see that it's much like dynamic scope. The subject has been explored a few times in this discussion.

Re: Dynamic Scoping in C++

#62
post #58
post #53

Earlier quoted context omitted.

Reader is like implicit parameters: dynamic scoping with static types. https://dl.acm.org/doi/10.1145/325694.325708

I know what Reader is, but my point still stands.

Okay... I wasn't suggesting you don't know what Reader is... you said:

>Reader is like a middle-ground between dynamic-scoping and explicit passing of a context argument around

I just wanted to point out that the-thing-which-Reader-is, is sometimes called "implicit parameters", and there are papers written about it.

Re: Dynamic Scoping in C++

#63
Hi! Author of DynamicScope here.

Regarding threads: It is correct that the current version of the template has a problem with multi-threaded programs. However, as adding 'thread_local' 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 only with thread_local.

Regarding Lambdas: I don'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 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.

Re: Dynamic Scoping in C++

#64

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

That is very cool! Do you have a link to that implementation? I would be very interested in the problems that arise when you want to provide a rock solid implementation of this.
Post reply on HN