Scoped variables

[jonathan.brachthaeuser]

Proper dynamically scoped variables are especially important in presence of multiple resumptions. I can't point out Oleg et al.'s paper often enough on this [1].While at first it might seem like it is difficult to get that part of the design right, I am fully convinced that (conceptually) storing scoped variables on the stack is the right thing to do. Delimited continuations capture parts of the stack, including the dynamic variables contained therein.CheersJonathan[1]: http://homes.sice.indiana.edu/ccshan/dynscope/DDBinding.pdf
-------- Original message --------From: Ryan Schmitt <rschmitt at pobox.com> Date: 7/19/19  21:46  (GMT+01:00) To: Ron Pressler <ron.pressler at oracle.com> Cc: loom-dev at openjdk.java.net, Jon Harper <jon.harper87 at gmail.com> Subject: Re: Scoped variables My knee-jerk reaction is "yes, yes it is." To me, the main valueproposition of Loom is that we finally get to do structured programmingagain, and scoped variables pair better with this idea than fiber-localvariables. Having said that, it's possible that concerns of migrationcompatibility (where fiber-based code exists side-by-side with explicitlyevent-driven async code) may render this approach unworkable in practice.On Fri, Jul 19, 2019 at 5:21 AM Ron Pressler <ron.pressler at oracle.com>wrote:> We haven’t had much time to spend on this recently, and we certainly have> no conclusions as of yet,> but this is sure to become an area of focus once the more basic areas of> the API have stabilized.>> We are, however, very much interested in hearing some thoughts about this.> In particular, is the idea> of a binding with a dynamic scope that reverts to the old value when we> exit the scope a better one> than the existing un-scoped lifetime of ThreadLocals, whose value persists> until the next time it is set?>> Ron>>> On July 11, 2019 at 6:38:37 PM, Jon Harper (jon.harper87 at gmail.com) wrote:>> Hi list,> I read with much interest the "scoped variable" discussion from> December 2018:> https://mail.openjdk.java.net/pipermail/loom-dev/2018-December/thread.html>>> Towards the end of the conversation, the following was stated:>> > dean.long at oracle.com ; 12/7/18 1:15 PM> > Now might be a good time to start a discussion on how we want scoped> variables to be created and named.> > Doug Lea dl at cs.oswego.edu ; Sun Dec 9 14:32:07 UTC 2018> > Or backing up further, how about a discussion of use cases that should> be covered?>> Has this been done and is there a link to a conclusion ?>> My favorite use case is implementing what various logging frameworks> call Diagnostic Contexts in a way that is safe for everyone, whether> they use threads manually or abstracted behind Executors (or using> loom's fibers). I think the current agreement is that Diagnostic> Contexts are too dangerous (currently implemented with threadlocals)> because they can spill from one context to another when using> Executors, resulting in false logs. Logs are a prime example where you> don't want to explicitly pass a context object everywhere but still> want your logs to display contextual informations (like a request id).> This is especially true when you want to add a new log somewhere in> the code where the context is not passed and you have to backtrack all> the call chain and add the context object to all the intermediate> method arguments.>> Cheers,> Jon>