proposal: deprecate dynamic states

proposal: deprecate dynamic states

[Andy Wingo]

Hi,

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.

Andy
-- 
http://wingolog.org/

Re: proposal: deprecate dynamic states

[Mark H Weaver]

Hi Andy,

Andy Wingo <wingo@pobox.com> 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.

I strongly agree with this.

> If no one objects, I'll push something that does this in the next
> couple days.

Sounds good to me!

     Mark

Re: proposal: deprecate dynamic states

[Ludovic Courtès]

Andy Wingo <wingo@pobox.com> skribis:

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

Fine with me!

Ludo’.

Re: proposal: deprecate dynamic states

[Andy Wingo]

Hi :)

It took more than a couple days, ahem, but let's do this.  Just a
heads-up.

Andy

On Sun 09 Mar 2014 18:33, Andy Wingo <wingo@pobox.com> writes:

> Hi,
>
> 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.
>
> Andy

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