search

Gabriella439 / Haskell-Pipes-Safe-Library

Safety for the pipes ecosystem
BSD 3-Clause "New" or "Revised" License
26 stars 21 forks source link

MonadUnliftIO instance for SafeT? #34

Open merijn opened 6 years ago

merijn commented 6 years ago

It seems like SafeT nicely fits Snoyman's MonadUnliftIO design, and having an instance for it would make it drastically simpler to write code that supports both Pipes and Conduit. In addition the unliftio-core library has a very minimal dependency footprint (only depending on base and transformers on which pipes already depends anyway).

Gabriella439 commented 6 years ago

I'm not convinced that UnliftIO is the correct abstraction. I think the correct abstraction is either MonadManaged:

https://hackage.haskell.org/package/managed-1.0.6/docs/Control-Monad-Managed.html#t:Managed

... or an equivalent type class replacing Managed with Data.Acquire.Acquire

merijn commented 6 years ago

That may well be, but a significant portion of the ecosystem doesn't use MonadManaged, but ResourceT or MonadUnliftIO. For some of my libraries I'm trying to expose a streaming interface that can be used with either pipes or conduit (and maybe machines if I ever get around to that), but the lack of shared abstraction is making it a real pain for me. Having MonadUnliftIO at the base of both would drastically simplify my life.

Alternatively, I could simply make the pipes interface require MonadResource and rely on ResourceT over SafeT, but that doesn't seem like it plays as nice with Pipes.

Gabriella439 commented 6 years ago

I still think the best solution would be to add a MonadAcquire class to the resourcet package. I think that has nice laws and would satisfy most use cases, plus it's an addon to an already widely used package