Parameters look interesting, but the man page suggests that there's a pretty significant overhead in code tree nodes to using them. Do you think we can get that functionality cheaper?
The thing I like about my approach is the simplicity - everything expands to sets. If we had parameters, we'd probably want to modify set so that it worked on them. In that case, this approach would still work, and would be the most idiomatic way to do it.
It also separates functionality nicely, since it would work with any thread mechanism that allowed per-thread variables (all of them). Because it only expands to set calls, it's a general mechanism for dynamic binding, and the thread stuff should "just work" if they're used together.
We can't know what is "significant overhead" without testing. Arc already has its own overhead, so for all we know the added overhead of using parameters might be utterly insignificant. Or not.
Certainly a layered approach is a good idea: an underlying mechanism that provides bug-free dynamic binding functionality, and then a macro layer that allows people to use the functionality in a convenient and easy way.
You might be able to use set with MzScheme's thread local variables if you also used something like using "protect" to restore values on exceptions; but you wouldn't be able to use set with MzScheme's parameters because you need to specify what is the scope that you want the parameter to have a new dynamic value within.
The key challenge to using MzScheme's parameters is that you'd need a way to have Arc compile a variable reference "foo" into a Scheme parameter call "(foo)". However if someone did that I expect the result would be simpler because we wouldn't need the code to set and restore the values ourselves.
