
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 4 Nov 2015, at 13:04, Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">This got me curious, so I just added a `sourceToList` function to master:<div><br></div><div><a href="https://github.com/snoyberg/conduit/commit/289f671cb7669c4aec78d8e77f01f2ace165d73a">https://github.com/snoyberg/conduit/commit/289f671cb7669c4aec78d8e77f01f2ace165d73a</a><br></div></div></blockquote></div><br><div>Having spent a day thinking this over…</div><div><br></div><div>Nothing with the type `Source m a -> m [a]` can work for my second example - the one where I use runExceptionT to discharge the MonadThrow constraint. This is because once you use runExceptionT you have pushed yourself into the situation where in case of error there is no ‘return value’. </div><div><br></div><div>It’s not that I care about that per se - if there is an error then the return value is no use to me - but unfortunately that has knock-on implications on laziness.</div><div><br></div><div>The Writer monad solution pushes out the return value incrementally by a ‘side-channel’ rather than using the return value and it’s that property which lets it work even in the presence of runExceptionT.</div><div><br></div><div>Another approach which would work though is to provide a newtyped Identity monad which handles MonadThrow by _|_, which would allow you to regain laziness (?)</div><div><br></div><div>Jules</div><div><br></div></body></html>