Re: proposal: deprecate dynamic states

[Josep Portella Florit]

On Sun 09 Mar 2014 18:33, Andy Wingo <address@hidden> writes:
> The manual claims that you can use fluids as thread-local variables,
> but that's not really true -- we expose this strange "dynamic state" 
> interface that lets you have one dynamic state used by multiple 
> threads.  Pretty strange stuff.
> 
> Normally I wouldn't be against "extra functionality" but this one
> makes no sense.  We need something that is "thread-local state" and 
> fluids/parameters should be that thing -- and yet, we are prevented
> from doing by the dynamic state interface.  (Of course, that doesn't
> stop us from using fluids in this way; I'm sure there are many bugs
> out there.)
> 
> So my proposal is to deprecate the dynamic state interface.  It's 
> nonstandard, I've never heard of anyone using it, and it's actively 
> harmful.  If no one objects, I'll push something that does this in
> the next couple days.

Guile's `make-dynamic-state` and `with-dynamic-state` seem to be the
equivalent to Racket's `current-parameterization` and
`call-with-parameterization`.  I think this functionality is useful: you
can take a "snapshot" of the parameters to use it later (see my last
message in <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20938>).

Guile's `current-dynamic-state` doesn't seem to have an equivalent in
Racket.  I see it allows you to use the same dynamic state in different
threads, which I agree is strange, given that parameters are meant to be
thread-local variables.

Maybe you should simply deprecate `current-dynamic-state`.