Made 'withRunInIO' fully polymorphic

[effectfully]

withRunInIO was

withRunInIO :: MonadUnliftIO m => ((m a -> IO a) -> IO b) -> m b

and now it's

withRunInIO :: MonadUnliftIO m => ((forall a. m a -> IO a) -> IO b) -> m b

I also replaced withUnliftIO by withRunInIO everywhere in the codebase. Docs are updated accordingly, but please verify. I think it should be mentioned somewhere in the library that withUnliftIO now has quite a little number of uses (basically, if you want to put a UnliftIO m into some data type) and withRunInIO is a preferable function.

[snoyberg]

I think it should be mentioned somewhere in the library that withUnliftIO now has quite a little number of uses

I'm on board with that, do you want to include that note in the Haddocks for withUnliftIO itself?

[snoyberg]

Can you add a comment to the ChangeLog about the change in type signature, and update the version number to 0.1.1.0? Also, I believe we'll now need a lower bound on unliftio-core in unliftio.

[effectfully]

Done.

Personally, I think building the library around withRunInIO would make it easier to comprehend and there also won't be any hacky newtypes lying around which I think is a benefit. askUnliftIO can of course be implemented in terms of withRunInIO. What do you think?

In any case it's a great library: simple and useful. I'm currently in the pass-environments-explicitly camp, but I might reconsider this position in future, because now there is a sensible alternative. Thanks for this.

[snoyberg]

You mean moving it into the type class itself as a method, providing default implementations for both methods, and using MINIMAL to ensure one of them gets an instance? That sounds pretty good to me.

…

On Mon, Jan 1, 2018, 8:41 PM effectfully ***@***.***> wrote: Done. Personally, I think building the library around withRunInIO would make it easier to comprehend and there also won't be any hacky newtypes lying around which I think is a benefit. askUnliftIO can of course be implemented in terms of withRunInIO. What do you think? In any case it's a great library: simple and useful. I'm currently in the pass-environments-explicitly camp, but I might reconsider this position in future, because now there is a sensible alternative. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADBBxHGI2iIdJNDthwuQveU-7FL0KbMks5tGSblgaJpZM4RQHzj> .

[effectfully]

This discussion is irrelevant here, so I opened an issue.

Please say if there is something else that should be fixed in the pull request.

[snoyberg]

Thanks!