> > 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe