<p>Is it possible that you are puuling in two different versions of the package that defines the MonadThrow class?</p>
<p>That is, package a was built against version 1, but package b was built against version 2? This would make GHC think the type-class were incompatable.</p>
<p>This is just a guess - I have not tried what you are trying.</p>
<div class="gmail_quote">On Jun 2, 2012 6:35 PM, "Myles C. Maxfield" <<a href="mailto:myles.maxfield@gmail.com">myles.maxfield@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To: Michael Snoyman<br>
CC: haskell-cafe<br>
<br>
Hello,<br>
I'm having a problem working with the conduit library, and was hoping<br>
you could help me out.<br>
<br>
Data.Conduit re-exports ResourceT, MonadResource, and MonadThrow (but<br>
not ExceptionT) from Control.Monad.Trans.Resource. I have a conduit<br>
which operates on a monad in the MonadThrow class. I am trying to<br>
figure out which MonadThrow class this should be (the<br>
Data.Conduit.MonadThrow class, or the<br>
Montrol.Monad.Trans.Resource.MonadThrow class, since apparently GHC<br>
doesn't recognize them as the same, even though one is just a<br>
re-export of the other).<br>
<br>
If a user of this conduit wants to chain this conduit up with<br>
something like sourceFile, the underlying monad has to be a member of<br>
Data.Conduit.MonadResource and whatever MonadThrow class I chose to<br>
use. I would like to be able to use an existing instance to lift the<br>
class of the inner monad to the class of the entire monad stack (so I<br>
don't have to tell the user of my conduit that they have to define<br>
their own instances), and the only rule that I can find that does that<br>
is the following from Data.Conduit:<br>
<br>
Data.Conduit.MonadThrow m => Data.Conduit.MonadThrow (Data.Conduit.ResourceT m)<br>
<br>
However, GHC doesn't seem to think that<br>
Control.Monad.Trans.Resource.ExceptionT is an instance of<br>
Data.Conduit.MonadThrow:<br>
<br>
No instance for (Data.Conduit.MonadThrow (ExceptionT IO))<br>
arising from a use of `.....'<br>
<br>
Control.Monad.Trans.Resource has a similar instance:<br>
<br>
Control.Monad.Trans.Resource.MonadThrow m =><br>
Control.Monad.Trans.Resource.MonadThrow<br>
(Control.Monad.Trans.Resource.ResourceT m)<br>
<br>
but because sourceFile operates in the Data.Conduit.MonadResource<br>
class, and Control.Monad.Trans.Resource.ResourceT isn't a member of<br>
that class (it's only a member of<br>
Control.Monad.Trans.Resource.MonadResource), that doesn't help:<br>
<br>
No instance for (Data.Conduit.MonadResource<br>
(Control.Monad.Trans.Resource.ResourceT (ExceptionT IO)))<br>
arising from a use of `.....'<br>
<br>
It should be noted that neither module defines anything like the following:<br>
<br>
MonadResource m => MonadResource (ExceptionT m)<br>
<br>
It seems like the underlying problem here is that:<br>
1) I am required to use the Control.Monad.Trans.Resource.ExceptionT<br>
class, because Data.Conduit doesn't re-export it<br>
2) I am required to use the Data.Conduit.MonadResource class, because<br>
sourceFile and others require it<br>
3) There doesn't seem to be an existing instance that bridges between the two.<br>
<br>
This seems like a fundamental flaw with re-exporting; it can only work<br>
if you re-export every single last thing from the original module.<br>
This doesn't seem tenable because the orignal module might not be<br>
under your control, so its author can add new symbols whenever he/she<br>
wants to.<br>
<br>
I see two solutions to this problem:<br>
1) Re-export Control.Monad.Trans.Resource.ExceptionT in Data.Conduit.<br>
This will work until someone adds something to the resourcet package<br>
and someone wants to use the new addition and Data.Conduit.ResourceT<br>
in the same stack<br>
2) Don't re-export anything in Data.Conduit; make sourceFile and<br>
others explicitly depend on types in another module, but this might<br>
break compatibility with existing programs if they use fully-qualified<br>
symbol names.<br>
3) Make anyone who wants to use a monad stack in MonadThrow and<br>
MonadResource define their own instances. This is probably no good<br>
because it means that many different modules will implement the same<br>
instance in potentially many different ways.<br>
<br>
I feel like option 2) is probably the best solution here. I'm<br>
perfectly happy to issue a pull request for whichever option you think<br>
is best, but I don't know which solution you think is best for your<br>
project. What do you think?<br>
<br>
--Myles<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div>