MonadIO remains Haskell 98. This means that it has a chance of actually getting into core libraries in a standardizable form and eventually making it into the report. The problem is there is no full description of MultiParamTypeClasses + FunctionalDependencies that is compatible with all the implementations out there to bless and readily standardize. GHC and Hugs (and older GHCs) disagree on a number of corner cases of how this works. Worse, the corner cases where they disagree come up because of how GHC desugars things into type families, so describing current GHC behavior really would require dragging into the report pretty much all of OutsideIn(X), which is an order of magnitude more complicated than the entire report today. So, yes, if we ever want to be able to see the bulk of the combinators in base lifted generalized and have that fact become enshrined in a standard then there is a very real reason to favor MonadIO. -Edward On Wed, Jul 29, 2015 at 9:30 AM, Matthias Hörmann wrote:

Is there a particular reason to still push MonadIO even though MonadBase (from transformers-base) is a cleaner, more general approach that also fits much more nicely with more powerful abstractions like MonadBaseControl (from monad-control)?

I know it uses MultiParamTypeClasses but is there another, more practical reason for not using MonadBase IO instead of MonadIO?

On Thu, Jul 23, 2015 at 11:29 PM, Ryan Scott wrote:

...

It looks like GHC's internal MonadIO was replaced with the one from transformers in 2013 [1], so this is already fixed.

Also, +1 on the MonadIO to base suggestion, now that's there's some momentum behind that idea.

---------- [1] http://git.haskell.org/ghc.git/blobdiff/b13d546f9c454e6d2a15c20a3e10ec47328e... _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries