Closed ghost closed 5 years ago
Okay, so here's my preliminary fork removing MonadException and replacing it with MonadMask: https://github.com/marcinmrotek/haskeline (I also allowed myself to move all unexported modules to an Internal subtree and exporting them in .cabal, because I honestly think it's poor sport to prevent users from importing some modules no matter what. Feel free to re-hide them, though)
Is this consciously ignored, @judah? This custom System.Console.Haskeline.MonadException
thing makes it impossible to use this package when there is opaque monad transformer in monad stack below InputT
.
Chances are that that opaque monad transformer is instance of conventional type classes like MonadThrow
, MonadCatch
, etc., but not System.Console.Haskeline.MonadException
. Even when I actually have ability to change definition of that monad transformer to derive your MonadException
, this makes me depend on haskeline
where I don't want to depend on it, only to be able to use it later in monad stack with InputT
.
So, this is a very uncomfortable situation.
I tend to be cautious about adding dependencies to Haskeline, since they also end up as dependencies of GHC and in some sense become "blessed" (e.g., automatically included in the Haskell platform). So I'd rather the Haskell community first decide on a package for this purpose before using it in Haskeline. I see a few that are actively developed, including monad-peel
, monad-control
and exceptions
.
I'd suggest the following way forward: send an email to the Haskell lists (including ghc-devs@ and libraries@) to try to get feedback on whether exceptions
or another package should be used for this purpose. If there's a clear consensus, then I'm open to a patch to replace Haskeline's MonadException with it.
It seems to me that Control.Monad.Catch from exceptions already does the job of generalizing exception handling functions, and thus reimplementing it in MonadException only causes Haskeline to be incompatible with libraries that use the exceptions package.