search

snoyberg / classy-prelude

A typeclass-based Prelude.
108 stars 15 forks source link

Avoid mixing MonadIO and MonadBase IO #78

Closed k0ral closed 9 years ago

k0ral commented 9 years ago

In ClassyPrelude are currently exported some functions that use the MonadIO typeclass (e.g. re-exports from Control.Concurrent.MVar.Lifted), and others that use the MonadBase IO one (e.g. ClassyPrelude.atomically).

Seeing as both provide basically the same feature, I would expect ClassyPrelude to be a consistent bundle and take sides on this matter (preferably the MonadBase IO one, if you ask me).

I wouldn't know how to implement it though, turning a MonadBase IO m => m a into a MonadIO m => m a, or the other way round. Do you have any insights ?

snoyberg commented 9 years ago

Unfortunately, this is unavoidable with the current library ecosystem. Most libraries we depend on prefer MonadIO, whereas monad-control and its users need MonadBase IO generally. I agree, it's not ideal.

k0ral commented 9 years ago

Then you might want to define the following shortcut in ClassyPrelude:

{-# LANGUAGE ConstraintKinds #-}
type MonadBaseIO m = (MonadBase IO m, MonadIO m)
gregwebs commented 9 years ago

That is what I do. I call it ControlIO

snoyberg commented 9 years ago

@gregwebs If you think it's worth including such as type synonym, go for it. But we're not going to be able to solve the general problem of MonadBase IO vs MonadIO, so closing this issue.