On Thu, Jan 19, 2012 at 10:35 AM, Vincent Hanquez <t...@snarc.org> wrote:
> On 01/19/2012 08:14 AM, Gregory Collins wrote:
>>
>> Speaking of the migration issue; it should be possible to have an
>> enumerator <-> conduit wrapper library to help people continue to use
>> their enumerator-based code for awhile (and vice-versa).
>
>
> A bit out of topic and definitely not answering the question, but for
> asn1-data,
> i want to move away from the data feeding business, and just relying on the
> attoparsec API.
>
> That let the user choose the feeding "style" by plugin either an existing
> attoparsec
> plugin package (attoparsec-{conduit,enumerator,iteratee}) or dealing with
> the Result
> type directly.
>
> This is also possible when using cereal (Data.Serialize).
>
> I think more libraries in the enumerator camp or iteratee camp should look
> if they need
> to control input or not. unless there's something i missed :-)
>
> --
> Vincent @vincenthz
That's the reason, for example, that zlib-bindings exists. It's a
mid-level binding to the zlib C library. I wouldn't want to write code
against it in general, but it makes it very easy to create zlib-enum
and zlib-conduit.
Michael
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
