Closed Gabriella439 closed 11 years ago
Thanks Gabriel. I also prefer the first approach since it allows you to reuse the same code in different monads, I'd be happy to get your patch. However, would it make sense to embrace MonadIO
as a base monad throughout pipes-network
instead of IO
? I confess that I don't completely understand the trade-offs of doing this, and that I haven't yet checked your new type-families code, so perhaps this idea doesn't even make sense.
Oh, I see now. Base m
should be the monad at the very bottom of the transformer stack, so it must be IO
and not just any MonadIO
instance.
Yes, I just changed the behavior of Base m
as I was writing up this issue so that it now points directly to the true base monad and not the one directly below SafeT
. So you don't need the MonadIO
part any longer with that fix.
This was fixed by 1d16283d558b408e63b6286e95d50ddc9228c0bb
So I just merged in the type families stuff into
pipes-safe
this morning but that brokepipes-network
. There are two ways to fix it:Base m ~ IO
constraint to all your safe functionsProxy a' a b' b (SafeT IO)
or the simplerEffect' (SafeT IO)
when possibleThe second approach is what I had in mind when I designed
pipes-safe
, but after seeing what you did I think I like your version better since it lets you use other monads (even ones that are notpipes
-related) without lifting.I already forked your library and added the necessary
Base m ~ IO
constraint everywhere, so if you want I can submit a pull request to add this in.