Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Looking for feedback: Move from monad-control & lifted-base to unliftio. #22

Open
iand675 opened this issue Jun 20, 2018 · 6 comments
Open

Comments

@iand675
Copy link
Owner

iand675 commented Jun 20, 2018

I'm considering switching over from uses of monad-control to unliftio. A few of the reasons:

  • New yesod versions don't provide instances for MonadBaseControl in Handlers.
  • There are noted issues with bracketing in the context of MonadBaseControl (see https://www.fpcomplete.com/blog/2017/06/tale-of-two-brackets). In the case of datadog's usage, bracketing is one of the main reasons that we use it, so I'd like to restrict usage to a safer subset of monad transformers.

Any feedback is welcome, but thinking about doing a major release with #18 and #21 soon, so it'd be a good time to make the transition.

@iand675
Copy link
Owner Author

iand675 commented Jun 20, 2018

@dfithian would be particularly interested to hear from you on this if you've got any opinions on it. I expect people using withDogStatsD itself in one of the 'dangerous' transformers are few and far between.

@dfithian
Copy link
Collaborator

dfithian commented Jun 22, 2018 via email

@dfithian
Copy link
Collaborator

dfithian commented Jul 2, 2018

This is the first time I've heard of unliftio. It looks like the advantage is that you can provide an implementation for running a monad transformer stack without pinning the makeup of the monad stack itself. Is that right? In addition, another advantage would be that one could nest ResourceT blocks? Certainly the latter is a beneficial result; many a time have I been bit by accidentally embedding multiple runResourceT calls.

@dfithian
Copy link
Collaborator

dfithian commented Jul 2, 2018

I would say that given the ResourceT problem presents as a runtime error I'd be very careful about this change and make sure that it's not only called out in the README. Also potentially not completely rewriting the API but deprecating the old API and providing a new implementation.

@dfithian
Copy link
Collaborator

dfithian commented Jul 6, 2018

Okay I'm totally on the MonadUnliftIO bandwagon now. Having used it this week I'm heavily in favor of banishing ExceptT to purgatory.

@iand675
Copy link
Owner Author

iand675 commented Jul 7, 2018

👍 glad to hear it. I think given that Yesod has dropped MonadBaseControl, it leaves us in a less-than-desirable position for popular usage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants