[conduit 0.2.x] generalizing sourceIO?

Hi all, I was just wondering - would it be reasonable to generalize sourceIO :: ResourceIO m => IO state -> (state -> IO ()) -> (state -> m (SourceIOResult output)) -> Source m output to sourceIO :: ResourceIO m => IO state -> (state -> IO ()) -> (state -> m (state, SourceIOResult output)) -> Source m output so that the state could be "updated" while producing results? I've found there are a few situations where the lack of "state threading" is forcing me to use MVars where it would actually be a lot nicer and simpler to just thread an accumulator. AFAICT from the sourceIO implementation there shouldn't really be any problem with doing this. Am I overlooking something? Regards,

Bardur Arantsson wrote:
Hi all,
I was just wondering - would it be reasonable to generalize
sourceIO :: ResourceIO m => IO state -> (state -> IO ()) -> (state -> m (SourceIOResult output)) -> Source m output
to
sourceIO :: ResourceIO m => IO state -> (state -> IO ()) -> (state -> m (state, SourceIOResult output)) -> Source m output
so that the state could be "updated" while producing results?
Would it not be possible to achieve what you want with sourceState: http://hackage.haskell.org/packages/archive/conduit/0.2.0/doc/html/Data-Cond... Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Erik de Castro Lopo wrote:
Would it not be possible to achieve what you want with sourceState:
http://hackage.haskell.org/packages/archive/conduit/0.2.0/doc/html/Data-Cond...
No it wouldn't, but maybe that calls for a function sourceStateIO that has all the features of sourceIO and sourceState. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

On Tue, Feb 7, 2012 at 11:18 PM, Erik de Castro Lopo
Erik de Castro Lopo wrote:
Would it not be possible to achieve what you want with sourceState:
http://hackage.haskell.org/packages/archive/conduit/0.2.0/doc/html/Data-Cond...
No it wouldn't, but maybe that calls for a function sourceStateIO that has all the features of sourceIO and sourceState.
That might make sense. There are definitely cases where it would be useful. I don't want to change the type of sourceIO to the suggested type, since: 1. It complicates things for the common case 2. Returning a tuple means that when we return IOClosed, we still need to return a state, even though it doesn't make sense. This should be a fairly minor change, I think I'll throw it in soon. Michael
Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

On Wed, Feb 8, 2012 at 9:04 AM, Michael Snoyman
On Tue, Feb 7, 2012 at 11:18 PM, Erik de Castro Lopo
wrote: Erik de Castro Lopo wrote:
Would it not be possible to achieve what you want with sourceState:
http://hackage.haskell.org/packages/archive/conduit/0.2.0/doc/html/Data-Cond...
No it wouldn't, but maybe that calls for a function sourceStateIO that has all the features of sourceIO and sourceState.
That might make sense. There are definitely cases where it would be useful. I don't want to change the type of sourceIO to the suggested type, since:
1. It complicates things for the common case 2. Returning a tuple means that when we return IOClosed, we still need to return a state, even though it doesn't make sense.
This should be a fairly minor change, I think I'll throw it in soon.
How's this? https://github.com/snoyberg/conduit/commit/7ab2a34d5baa40b7f98cec19430516152... Michael

On 02/08/2012 09:07 AM, Michael Snoyman wrote:
On Wed, Feb 8, 2012 at 9:04 AM, Michael Snoyman
wrote: On Tue, Feb 7, 2012 at 11:18 PM, Erik de Castro Lopo
wrote: Erik de Castro Lopo wrote:
Would it not be possible to achieve what you want with sourceState:
http://hackage.haskell.org/packages/archive/conduit/0.2.0/doc/html/Data-Cond...
No it wouldn't, but maybe that calls for a function sourceStateIO that has all the features of sourceIO and sourceState.
That might make sense. There are definitely cases where it would be useful. I don't want to change the type of sourceIO to the suggested type, since:
1. It complicates things for the common case 2. Returning a tuple means that when we return IOClosed, we still need to return a state, even though it doesn't make sense.
This should be a fairly minor change, I think I'll throw it in soon.
How's this?
https://github.com/snoyberg/conduit/commit/7ab2a34d5baa40b7f98cec19430516152...
Michael
Looks great, thanks :).
participants (3)
-
Bardur Arantsson
-
Erik de Castro Lopo
-
Michael Snoyman