[Haskell-cafe] Conduits: Is Source a valid instance of Monad?

[Michael Snoyman]

In 0.4, Source technically has a Monad instance, but it's not really
useful in the same way the instance Aristid is referring to. In order
to get that instance, we would need to introduce a newtype wrapper.

On Wed, Apr 4, 2012 at 5:55 PM, Paul Liu <ninegua at gmail.com> wrote:
> Thanks! I failed to notice this instance declaration in the document.
>
> But I'm still curious as to whether a Monad instance for Source makes
> any sense, since in 4.0 all of Source/Conduit/Sink would share the
> same implementation.
>
> Regards,
> Paul Liu
>
> On Tue, Apr 3, 2012 at 6:25 PM, yi huang <yi.codeplayer at gmail.com> wrote:
>> On Wed, Apr 4, 2012 at 4:48 AM, Paul Liu <ninegua at gmail.com> wrote:
>>>
>>> Is there any follow up on this?
>>>
>>> I was wondering what is the best way to sequence a number of sources
>>> together. Anybody gave a further thought on this?
>>
>>
>> I believe sequence sources together can already be done by `Monoid`
>> instance.
>>
>>>
>>>
>>> Regards,
>>> Paul Liu
>>>
>>> On Tue, Dec 27, 2011 at 3:45 PM, Aristid Breitkreuz
>>> <aristidb at googlemail.com> wrote:
>>> > Hi all,
>>> >
>>> > As you may have noticed, Michael Snoyman has been working on an
>>> > alternative approach to I/O, called conduits. You can find it here:
>>> >
>>> > https://github.com/snoyberg/conduit
>>> >
>>> > When looking at the Source type (explained here:
>>> > http://www.yesodweb.com/blog/2011/12/conduits), I noticed that they
>>> > seem to behave "like lists", and naturally wondered if I could write a
>>> > Monad instance for them. But first, let's have a brief look at the
>>> > definition of Source:
>>> >
>>> > data SourceResult a = Open a | Closed
>>> >
>>> > data PreparedSource m a = PreparedSource
>>> >     { sourcePull :: ResourceT m (SourceResult a)
>>> >     , sourceClose :: ResourceT m ()
>>> >     }
>>> >
>>> > newtype Source m a = Source { prepareSource :: ResourceT m
>>> > (PreparedSource m a) }
>>> >
>>> > ResourceT deals with resource acquisition and releasing (making sure
>>> > that all resources are released), and provides a an abstraction over
>>> > IORef/STRef. For our purposes here, ResourceT is probably close enough
>>> > to IO.
>>> >
>>> >
>>> > So now the question again is, can we write a Monad instance for this?
>>> > I have been able to write join (concatenate) and return (a source with
>>> > a single non-repeated) element.
>>> >
>>> > https://gist.github.com/1525471
>>> >
>>> > I _think_ it behaves properly like a Monad, but I'm not quite sure,
>>> > and neither was Michael. Greg Weber then suggested bringing the
>>> > question to this forum. What made the question difficult for me is
>>> > that this would be a stateful Monad transformer, so I'm not quite sure
>>> > how to test the Monad laws properly.
>>> >
>>> >
>>> > There's a second part to this question: If Source turns out not to be
>>> > a Monad, is it possibly a ZipList-like Applicative? And either way,
>>> > which is more useful: The list-like or the ziplist-like instances (of
>>> > Applicative/Monad)?
>>> >
>>> >
>>> >
>>> > Thank you,
>>> >
>>> > Aristid
>>> >
>>> > _______________________________________________
>>> > Haskell-Cafe mailing list
>>> > Haskell-Cafe at haskell.org
>>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Paul Liu
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>>
>>
>> --
>> http://yi-programmer.com/
>
>
>
> --
> Regards,
> Paul Liu
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe