[Haskell-cafe] Hangman game

[Yitzchak Gale]

Hi Paul,

You gave some suggestions of other styles of Haskell programming
that Ronald could try for his program. These styles are definitely
worth knowing, so if Ronald is not familiar with them, he may want
to try them out. However, in most cases, I think what Ronald
already did is nicer than what you are suggesting.

Paul Johnson wrote:
> The design reads very much like a straight translation
> from the imperative style, which is why so much of it is in the IO
> monad.  There is nothing wrong with this for a simple game like Hangman,
> but for larger games it doesn't scale.

It's a state monad, and most of his code is in that style. It doesn't
read to me like imperative style at all. And it scales beautifully.

There is a lot of liftIO, because that is the bulk of the work in
this program. But Ronald cleanly separated out the game logic,
and even the pure parts of the UI logic, into pure functions
like "handleGuess" and "renderGameState". I personally might
have kept a more consistently monadic style by writing those
as pure monads, like:

handleGuess :: MonadState GameState m => Char -> m ()
renderGameState :: MonadState GameState m -> m String

In certain situations, that approach gives more flexiblity.
Like for refactoring, or adding new features. But Ronald's
approach is also very nice, and I might also do that.

> 1: Your GameState type can itself be made into a monad.

Yes, it can. But StateT GameState IO is the perfect
monad for this game - writing a new monad would just be
reinventing the wheel. It would certainly be a good learning
experience for understanding the inner workings of the
state monad transformer, though.

> 2: You can layer monads by using monad transformers.  Extend the
> solution to part 1 by using StateT IO instead of just State.

I think he is already using that type.

> 3: Your current design uses a random number generator in the IO monad.
> Someone already suggested moving that into the GameState.  But you can
> also generate an infinite list of random numbers.  Can you make your
> game a function of a list of random numbers?

He could, but I would advise against that technique. In more
complex games, you may need to do many different kinds of
random calculations in complex orders. Keeping a random generator
inside a state monad is perfect for that. And since Ronald already
set up the plumbing for the state monad, he is already home.

Generating an infinite list from a random generator "burns up"
the generator, making it unusable for any further calculations.
Sometimes that doesn't matter, but I think it's a bad habit. I admit
you'll catch me doing it sometimes though, in "quick and dirty"
situations like at the GHCi prompt.

> 4: User input can also be considered as a list.  Haskell has "lazy
> input", meaning that you can treat user input as a list that actually
> only gets read as it is required.  Can you make your game a function of
> the list of user inputs?  How does this interact with the need to
> present output to the user?  What about the random numbers?

That type of "lazy IO" is considered by many to be one of Haskell's
few warts. It is a hole in the type system that lets a small amount of
side-effects leak through, and even that small amount leads to bugs.

In many situations it's hard to avoid without making a wreck out
of your whole program structure (though more and more tools
are becoming available to help, such as the ByteString stuff).
Ronald did great without it - why resort to that?

All that said - this is clearly a matter of taste, of course.
Thanks for bringing up a variety of approaches.

Regards,
Yitz