[Haskell-cafe] broadcasting stateful computations

[Olaf Klinke]

Thanks everyone for the helpful suggestions!

Bryan Richer wrote:
> what if the TVar is part of the
> state s?
> (StateT IO) can't give any guarantees about when or how the state is
> broadcast, but using STM within StateT actions still can.

I don't understand this, but it may go into the same direction as:

Chris Smith wrote:
> I had the same suggestion.  However, you then no longer need StateT, as
> ReaderT is enough.  Using a `ReaderT (TVar s) IO a` will allow atomic
> changes to the state s, along with interleaved IO when it's done safely
> rather than in the middle of a transaction.

ReaderT (TVar s) IO is interesting! It does not solve the problem of
atomic modifications with side-effects, though. Currently I am
implicity using ReaderT (TVar s), by explicitly passing the TVar
around. 

In principle, for atomic modifications I have to get hold of a pure
version (s -> s) of the modification. Maybe within a monadic context.
But if determining this modification function is side-effectful, then
it can not depend on the initial contents of the TVar! 

This leads me to the conclusion that either 
(a) atomic modification by a Kleisli map is impossible and another
mechanism needs to ensure thread safety, or
(b) we need to keep two versions of the state: one private, pure s and
one public TVar s which we synchronize from time to time. The latter
can be accomplished with atomic writes. More on that below.  

Isaac Elliott wrote:
> What about creating a MonadState instance for the TVar?
Very neat, but it would not solve the atomicity problem, since the
update I have is not expressible as stateTVar. 

YueCompl wrote:
> I believe this is the use case for TMVar, use `takeTMVar` / `putTMVar` instead of `readTVar` / `writeTVar` will do.

TMVars appear non-empty for one thread only, as far as I understand. 
So any observer thread would be blocked while the worker thread is
updating the state? 
Not good for my use case. The observer thread will be a webserver. 
I'd rather have the webserver report old states than block. 

I have neglected to mention one aspect of my problem that might be
essential: All my state updates are monoidal. By that I mean that s is
a monoid with 
	s' <> s <> s = s' <> s 
and any effectful modification will be of the form 
f = \s -> (k s) >>= (\s' -> s' <> s)
for some k :: s -> m s.
This entails that instead of emitting modifications as functions I can
emit modifications as values. 

emitModification :: (Monad m, Monoid s) => 
  StateT s m a -> WriterT s (StateT s m) a
emitModification (StateT f) = WriterT $ StateT $ \s -> do 
   (a,s') <- f s 
   return ((a,s'),s')

broadcastModification :: (MonadIO m, Semigroup s) => 
  TVar s -> (WriterT s m) a -> m a
broadcastModification ref (WriterT m) = do 
   (a,s') <- m
   (liftIO.atomically) (modifyTVar ref (\s -> s' <> s))
   return a

Then 
\ref -> broadcastModification ref . emitModification
  :: (MonadIO m, Monoid s) => 
    TVar s -> StateT s m a -> StateT s m a

This has the additional charm that I can explicitly control when writes
to the TVar happen, by choosing which (StateT s m) blocks to enclose in
this wrapper. I might even set up my communication as a TChan, if the
observing thread maintains an own copy of state itself to merge the
updates s' into. 

Olaf