I have added an annotation to the paste. Right now it looks like you are not really using the state monad much. Currently the state monad is only running the score' function and then the state is passed manually from one loop iteration(wrong phrase, what is the right one?) to the next of score'.
Since you are passing around the state manually it seems like you might as well use the stateless version I presented in the annotation. On the other hand if I planned to use many functions that utilized the state monad I might use the stateful version in the annotation. This eliminates the need to pass the state around as a argument to `go`. Running the StateT monad above the pipe monad on the stack ends up being faster with the current version of GHC. If I wanted to share the state along the pipeline I might use the statefulest version. This would allow for several pipes to share the same state variable with out having to pass it around manually. This allows for state to be shared along the pipeline but is slower the the scoreStateful since the state monad is underneath the pipes monad. evalStateT statefulest board >-> pipe1 >-> pipe2 or to run on several piipes: flip evalStateT board (statefulest >-> pipe1 >-> pipe2) pipe1 and pipe2 can access the state now. Since pipe1 and pip2 can not access the board state from the state monad you probably would not have to pass it down the pipeline with yield as you did in your original function: yield (a', b') b' being the state. Hopefully future versions of GHC will be able to optimize away the speed differences between scoreSateful and scoreStatefulest. Not clear that it is coming anytime soon though since such an optimization would only work for monad layers that can commute. I messed up the type and and few other parts in my first annotation, hopefully I got it mostly right in the second. That should give you something to play with and think about. Let me know if you have any questions. On Mon, May 5, 2014 at 2:32 PM, Pierre R <[email protected]> wrote: > Hi, > > I have added a little pipes frontend to one of my pet example and I was > wondering how idiomatic (or not) it is. > > http://lpaste.net/103623 > > Basically instead of consuming a list with mapM (the `scores` function) I > am streaming input from stdin. Consequently I need to treat the end of game > differently than a bogus shot. > > Nothing to do with Pipes but I am not sure annotation 2 is better because > it forces all client `score` code to unwrap StateT whereas I only need the > state monad when I have to deal with a list of shots. Is there a more > idiomatic way to do this ? > > The github repo is here : > https://github.com/PierreR/afgame/tree/master/haskell > > Thanks for your feedback > > -- > You received this message because you are subscribed to the Google Groups > "Haskell Pipes" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > -- Patrick Wheeler [email protected] [email protected] [email protected] -- You received this message because you are subscribed to the Google Groups "Haskell Pipes" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected].
