Persist mutable state between requests

[easafe]

Persist mutable state between requests

[JordanMartinez]

You'd have to use a `Ref` and not the state monad.

[easafe]

I thought about that @JordanMartinez. But it seemed like such a common use case, I wondered if I was missing a more "pure" way to do it.

[JordanMartinez]

Since the state monad is just a boilerplate-free way to thread immutable pure state through a computation...

this :: MonadState Int m => m String
this = do
  original <- get
  put (original + 1)
  pure "done"

sameThing :: Monad m => Int -> m (Tuple Int String)
sameThing initialValue = do
  let original = initialValue
  let new = original + 1
  pure (Tuple new "done")

So, if you wrote a handler that uses the state monad, the problem is with the initial state value. Each time a request is made, the same initial state would be used in the resulting state monad computation. Using a counter as an example, the initial count would always start at 0 and be 1 at the end of the response. The next time a request comes in, it's back to 0, not 1.
If you wanted to track state across requests, you need to use mutable state. Your options are either ST (local) or Ref (global). Since ST doesn't work in this situation, you're only real option is Ref.

[cprussin]

Currently, I don't think there would be any way to use something like a StateT monad to thread mutable server state into your router. But as @JordanMartinez mentions, you can certainly use a Ref.

I'm not opposed to thinking about ways to make one of those other monad transformerss usable for this kind of situation (which would probably match the solution for #134). That said, I typically structure my apps following something very close to https://www.fpcomplete.com/blog/2017/06/readert-design-pattern. That article makes very compelling arguments why Ref is actually more appropriate for global app state. Presumably your app is your server, so server state is a synonym for global app state.

[easafe]

@cprussin would you say the remarks about exceptions apply to PureScript as well?

[cprussin]

wow this is a very late reply but somehow I missed your message @easafe . Yes I think the same logic for exceptions applies to purescript since the Effect monad in purescript has the same exception contract as IO (that is, anything running in it has an implicit assumption that it could throw an exception).