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