
On Mon, Apr 16, 2012 at 12:12 AM, Myles C. Maxfield
Thanks for responding to this. Some responses are inline.
On Sat, Apr 14, 2012 at 8:30 PM, Michael Snoyman
wrote:
[snip]
No, nothing so complicated is intended. Most likely you'll never return any leftovers from the second field of NeedInput. One other minor point: it's also possible that the second field will be used if the *downstream* pipe returns Done.
Just to help me understand, what is a case when you want to specify something in this field? I can't think of a case when a Conduit would specify anything in this case.
There are a number of examples in the built-in libraries. For example, Data.Conduit.Binary.takeWhile http://hackage.haskell.org/packages/archive/conduit/0.4.1.1/doc/html/src/Dat... [snip]
Why avoid Exceptions? It's the right fit for the job. You can still keep your conduit pure by setting up an `ExceptionT Identity` stack, which is exactly how you can use the Data.Conduit.Text functions from pure code. Really, what you need to be asking is "is there any logical way to recover from an exception here?"
I suppose this is a little off-topic, but do you prefer ExceptionT or ErrorT? Any exception/error that I'd be throwing is just a container around a String, so both of them will work fine for my purposes.
ExceptionT is a means to allow non-IO stacks to throw exceptions. ErrorT is only an instance of MonadThrow if the underlying monad is an instance of MonadThrow. Michael