Defining MonadCatch etc. instances for RIO? about rio

[snoyberg]

I'm on the fence about it. On the one hand: I think encouraging MonadCatch and MonadMask is a bad idea, as they lead to confusing behavior in many common monads (see https://www.snoyman.com/reveal/monad-transformer-state and https://www.youtube.com/watch?v=KZIN9f9rI34). On the other hand, the RIO case is completely safe, and adding the instances adds no extra dependencies. I'm open to input on this.

[roman]

I would love to see concurrency working nicely with rio, is it possible for concurrency to stop relying on MonadCatch and MonadMask and replacing it with whatever rio supports (I guess this is unliftio)? Also, if concurrency does this change, would it stop working with other tools?

I can relate why (even though it doesn't hurt) we would not like the RIO monad to extend from MonadCatch and MonadMask.

[barrucadu]

In principle concurrency could stop relying on MonadCatch and MonadMask, but it raises some interface questions.

If MonadCatch goes away, what does the type of forkFinally become? Would there need to be two of them: forkFinally, which doesn't catch exceptions; and forkFinallyWithExceptions which does? Does MonadSTM lose its MonadCatch superclass too? If MonadMask goes away, what happens to forkWithUnmask and forkOnWithUnmask?

---

I somehow get the feeling that there aren't that many people defining their own MonadConc instances in the wild, so I'm fairly ambivalent about (assuming the naming problem could be fixed) splitting the class up into something like:

class (Monad m, Ord (ThreadId m), Show (ThreadId m)) => MonadConc1 m where
    -- ...

class (MonadConc1 m, MonadSTM (STM m), MonadThrow m) => MonadConc2 m where
    type STM m :: * -> *
    throwTo :: Exception e => ThreadId m -> e -> m ()
    atomically :: STM m a -> m a

class (MonadConc2 m, MonadMask m) => MonadConc m where
    forkWithUnmask :: ((forall a. m a -> m a) -> m ()) -> m (ThreadId m)
    forkOnWithUnmask :: Int -> ((forall a. m a -> m a) -> m ()) -> m (ThreadId m)

[akhra]

Possible short-term solution: put `MonadCatch` and `MonadMask` instances in something like `RIO.Deprecated.Orphans`. That way they're canonically available until a better solution is found. Edit: Email replies do not support Markdown? Last time I do that...

[barrucadu]

I woke up this morning with some more thoughts about this (what exciting dreams I must have been having!). I'll put together a branch splitting the class up, probably next week, and see what it's like.

There is, however, the question of where a MonadConc (or whatever) instance for RIO should live. The concurrency package is supposed to be a drop-in replacement for Control.Concurrent.*, so I've kept its dependency footprint very light. The dependency graph grows quite a bit (and pulls in heavyweight things like text) if I add rio, so I would not want to provide instances in concurrency. Similarly, rio doesn't use concurrency at all so I expect the rio developers wouldn't want the instances in here. I guess the usual solution to that would be a concurrency-rio package providing orphans.

[snoyberg]

It seems like this is going to affect a number of instances besides MonadCatch and MonadMask. How about a rio-orphans package for all of these? I'd say we even keep it in the same repo. I'll move ahead with a PR.

[barrucadu]

A rio-orphans package would be a great solution from my perspective. When that's out I'll make a concurrency-orphans package with an instance for RIO, as probably no-one but me wants to maintain MonadConc instances.

[snoyberg]

See #65.