Closed glguy closed 5 years ago
Thank you!
anyone wanting to use MonadIO outside of the package can use liftIO as needed
FWIW, I don't think this addresses my comment elsewhere; they can use liftIO
to embed calls to e.g. Output
fields in their own code, but if they were wanting for some reason to embed their own monadic values in the Output
fields, liftIO
doesn't help with that. Granted, given that the m
isn't part of the Output
type, I don't see what possible value anyone could gain by embedding their own m
values in the Output
fields, so I doubt it's going to cause a lot of trouble.
MonadIO usage in this library was causing unnecessary
liftIO
calls to be littered across the package. The package doesn't need any of this generality, and anyone wanting to useMonadIO
outside of the package can useliftIO
as needed. It might make sense to rely onMonadIO
if there were other type classes in use as well, but without that the generalization is premature and make this more complex than needed to perform the task. This also cleans up some of the MonadFail needs that were coming up because of some uses offail
leaking outside of the other liftIO wrappers.