> > 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,