Changing the transducer of a channel whiles it's running (without creating a new channel): https://gist.github.com/rauhs/01d98084d9d2b9c9fd81

@rauh: aren't you clever!

there is no safe way to achieve changing a transducer on the fly

If it has state, then it will destroy the state and make the transducer possibly useless. Though, why wouldn't it be safe?

stateful transducers is one problem

there's no ordering semantics on when the swap!/reset! happens with respect to any other values flowing through the channel

you'll have to control that knob from the producing end of the channel

But fundamentlly transducers are applied once

the returned "process/reducing function" can be applied as many times as need be, but the process transformation happens only once

to distill the problem look at transduce

https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L6577

It will apply the transducer within the call to transduce. Transducer applications are once only

Yes it definitely has very limited use-cases. Though in my case I'm only using it for some CLJS stuff where I transform the events on my channel according to some given rules. And these rules can change over time

@ghadi: Yes, but the "only once application" is circumvented by just re-doing it manually on every value that's coming in. It's instantiated on every value (inefficient but for my use case ok)

when do the rules change? and can you be guaranteed in an async setting to change the rules before or after the value goes in the channel?

I actually don't know. The user provides the transducer. Though I allow the freedom to change it during the runtime of my library. If it does change, I'm currently tearing down my channel and set it up again. But with this I can just remove some of that complexity

you're trading complexity for brokenness

never a good trade 😃

Well, when I tear down the channel and set it up again I also brake all the state, so nothing is more broken than it already was

No that's fine, because when you close a channel, it should allow a transducer's arity-1 function (the completing function) to run properly and clean up

But i agree, not the finest thing to do. Basically I restrict the user to map/filter and other simpler transducers, which is fine. And the library is only a development tool. NEver makes it into production

Ok, I didn't mean to rain on the parade 😃

That's a good point, I should call the arity 1 function myself.

perhaps, but there's still no safe or clearly defined time to make the swap in the general case (beyond map filter)

If the code can guarantee Tear Down -> Drain -> Construct New, then it is fine

in that order

Well I'll intercept the swap with an add-watch and complete the old value which can push all its stuff out to the channel

I wonder if it'd make sense to differentiate (in clojure) between stateful and stateless transducers. hmm