[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposal: deprecate dynamic states

From: Josep Portella Florit
Subject: Re: proposal: deprecate dynamic states
Date: Sun, 26 Jun 2016 13:26:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

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 <>).

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`.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]