On Mon, Apr 16, 2012 at 12:12 AM, Myles C. Maxfield <[email protected]> wrote: > Thanks for responding to this. Some responses are inline. > > On Sat, Apr 14, 2012 at 8:30 PM, Michael Snoyman <[email protected]> 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/Data-Conduit-Binary.html#takeWhile [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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
