> > Still more importantly to me, I understand that anyhow if I intend > > to use IO or random numbers, I must design my strategy from the > > beginning as "encapsulated in a monad". Something like: > > > > class (Monad m) => Strategy m a where ... > > > That's not true at all, you can always pass this data to your strategy > entry points and let haskell get it lazily, though it is not as > intuitive as other aproaches,
That seems exactly what I had tried to do (and failed) in my original code. The Fixed type was to provide the list of moves: > data Fixed = Fixed [Move] deriving Show and instanciate a strategy that ignores the game to make decisions, just return the provided moves, then zeroes if ever exhausted: > instance Strategy Fixed where > proposeNext game s = case s of > Fixed [] -> (0, Fixed []) > Fixed (x:xs) -> (x, Fixed xs) but when using an IO Fixed, the questions were not repeated lazily as needed, as if the list of moves was entirely evaluated; so this failed: > askUntil :: String -> IO Fixed > askUntil name = liftM Fixed (sequence $ repeat askio) > where askio = putStr (name ++ ", pick a number: ") >> readLn I thought that sequencing [IO Move] to IO [Move] was what breaked lazyness, so I tried other ways to turn an [IO Move] into a IO Strategy, and failed. If I did not interpret correctly why this was not lazy, or if it is indeed possible to do otherwise can you please show me how? Thanks, Eric _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
