Replace conditions with dynamically scoped variables

[brson]

Conditions are a special case of dynamic scope, and the few conditions we have in std that make sense, like not_utf8 could simply be represented as a dynamic variable that represents the standard schemes for coping with unicode errors: failure, deletion, replacement char.

Nominating.

[emberian]

What in tarnation is a dynamic[ally scoped] variable?

[pnkfelix]

@cmr Here are some quick results from googling:

• Wikipedia: http://en.wikipedia.org/wiki/Scope_%28computer_science%29#Dynamic_scoping this link points out that while some single-threaded runtime systems use global variables to implement dynamic scope (and you just save/restore the old value on the stack), such an implementation strategy is a bad idea in the presence of multiple threads.
• SRFI 39: http://srfi.schemers.org/srfi-39/srfi-39.html The Scheme community has largely settled on the term "parameter (object)" for the concept of a variable whose state is computed from the (thread-local) stack, so that you can override e.g. the current output port (or exception-handler, or other state you do not want to thread through your procedure arguments) on one thread without disrupting others.
• Racket's parameterize documentation: http://docs.racket-lang.org/guide/parameterize.html This is perhaps a bit more readable than SRFI 39. It gives some small examples, and again points out that parameterize is a better solution than global variables (a la set!).

[nikomatsakis]

@cmr thread-local variables with a fancy name.

[pnkfelix]

@nikomatsakis I think there is still the intent that you shouldn't have to manually write the code that restores the previous value as you pop your stack.

But that should easily implementable via RAII; so yes, it basically comes down to a particular usage-pattern for thread-locals.

[emberian]

Ok, I didn't realize it was dynamic scoping as I was already familiar with.
This doesn't seem to be a very invasive change?

fluid_key!(name, type, val) => static $name: Fluid<$type> = Fluid($val);

// FluidRef is a non-sendable wrapper around *T since &'task isn't a thing
fn fluid::get(key: &Fluid) -> FluidRef {
local_data::get(transmute(key), |p| { ... })
}

fn fluid::set(key: &Fluid, val: T) -> FluidGuard {
local_data::modify(transmute(key), |o| o.map(|v| v.push(val)));
FluidGuard(key)
}

and the FluidGuard will just pop from the stack in TLS.

It's basically just a scope guard version of conditions, rather than using
closures.

Does this look about right?

On Mon, Dec 16, 2013 at 5:48 AM, Niko Matsakis [email protected]:

@cmr https://github.com/cmr thread-local variables with a fancy name.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10602#issuecomment-30651502
.

[nikomatsakis]

@pnkfelix Yes, that's an important detail. Using a dynamically scoped style also means that we can safely permit lifetime data, I believe, which is nice.

@cmr more or less, yes.

[pnkfelix]

Accepted "First major release", P-backcompat-libs

[Skrylar]

Does this proposal actually remove the concept of conditions, or just alter how they are implemented?

I rather like being able use conditions to set what behaviour should be taken when serious errors occur, especially since it lasts for all function calls within scope. It would be less elegant in my opinion to have to specify an enum to every function call to replace the functionality if it was removed.

[emberian]

It just changes how they're implemented.

On Fri, Dec 27, 2013 at 4:43 AM, Skrylar [email protected] wrote:

Does this proposal actually remove the concept of conditions, or just
alter how they are implemented?

I rather like being able use conditions to set what behaviour should be
taken when serious errors occur, especially since it lasts for all function
calls within scope. It would be less elegant in my opinion to have to
specify an enum to every function call to replace the functionality if it
was removed.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10602#issuecomment-31254217
.

[mitsuhiko]

That sounds a bit similar to my (no longer working) port of the stacked locals I use in my Python libraries to rust: https://gist.github.com/mitsuhiko/213892b73873f9d20920

I gave up using this though, almost needs syntax support to not be really annoying.

[brson]

Conditions are gone now, and we're no longer using dynamic scope for anything in std. For the sake of portability @alexcrichton and I are inclined to preserve this characteristic of std. Dynamic scope and conditions are still worth exploring, but not in std please. Nominating for removal from milestone.

[nikomatsakis]

On Wed, Feb 05, 2014 at 03:41:50PM -0800, Brian Anderson wrote:

Nominating for removal from milestone.

+1

[pnkfelix]

removing from milestone; reassigned P-low.

[treeman]

Visiting for triage, carry on. RFC?

[alexcrichton]

Conditions have actually long since been removed, so this can be closed now.

[pnkfelix]

@alexcrichton of course the dynamically-scoped variables described in my comment above correspond to the new thread-local API that I believe Niko was talking about this last week.

So while I do not mind this issue being closed, it is possible there is value in linking to the discussion in the comments above. Or maybe we're better off just starting fresh with a new ticket and/or RFC.

[alexcrichton]

I suspect a new TLS api will require an RFC, but we can leave this open in the meantime if you'd like.

[rust-highfive]

This issue has been moved to the RFCs repo: rust-lang/rfcs#300