[Haskell-cafe] Conduit Best Practices for leftover data

[Michael Snoyman]

On Mon, Apr 16, 2012 at 12:12 AM, Myles C. Maxfield
<myles.maxfield at gmail.com> wrote:
> Thanks for responding to this. Some responses are inline.
>
> On Sat, Apr 14, 2012 at 8:30 PM, Michael Snoyman <michael at snoyman.com> 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