[Haskell-cafe] Yet another Conduit question

[Michael Snoyman]

Firstly, what's the use case that you want to deal with lists? If it's for
efficiency, you'd probably be better off using a Vector instead.

But I think the inverse of `concat` is `singleton = Data.Conduit.List.map
return`, or `awaitForever $ yield . return`, using the list instance for
Monad. Your conduitMap could be implemented then as:

    conduitMap conduit = concat =$= conduit =$= singleton

Michael


On Thu, Jan 31, 2013 at 5:12 PM, Simon Marechal <simon at banquise.net> wrote:

> I am working with bulk sources and sinks, that is with a type like:
>
> Source m [a]
> Sink [a] m ()
>
> The problem is that I would like to work on individual values in my
> conduit. I can have this:
>
> concat :: (Monad m) => Conduit [a] m a
> concat = awaitForever (mapM_ yield)
>
> But how can I do it the other way around ? I suppose it involves pattern
> matching on the different states my conduit might me in. But is that
> even possible to do it in a "non blocking" way, that is catenate data
> while there is something to read (up to a certain threshold), and send
> it as soon as there is nothing left to read ? Or doesn't that make any
> sense in the context of Conduits (in the sense that this conduit will be
> recheck for input before the upstream conduits will have a chance to
> operate) ?
>
> Another approach would be to have a map equivalent:
>
> conduitMap :: Conduit i m o -> Conduit [i] m [o]
>
> But I am not sure how to do this either ...
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130201/70ff848d/attachment.htm>