[Haskell-cafe] GHCi infers a type but refuses it as type signature

Luke Palmer lrpalmer at gmail.com
Tue Jun 23 20:44:30 EDT 2009


On Tue, Jun 23, 2009 at 6:05 PM, Eric Dedieu <papa.eric at free.fr> wrote:

> Now, trying to avoid duplicate code at this very level of simplicity
> seems to require compiler extensions! Here it is:


On a higher level, in case you are interested, here's a description of how I
would model your problem.  Take this with a grain of salt: we are already in
the area where different haskell vets will model this in different ways.
This is one of many approaches...

Instead of possibly tying the game to its side effects inside a monad, I
would model the game as a pure data structure, and then have different
interfaces just talk about the pure structure.  Note: In the real world,
things would be more polymorphic, but I'll keep it concrete for expository
purposes:  For example:

newtype Game = MkGame [Char]

empty :: Game
empty = MkGame []

play :: Char -> Game -> (Bool, Game)
play x (MkGame mvs) = (x `elem` moves, MkGame (x:mvs))

moves :: Game -> [Char]
moves (MkGame mvs) = mvs

These constitute the only interface you have to Game; it is immoral to use
MkGame from here on out.  If you were being rigorous, these would go into a
module with export list (Game, empty, play, moves).

Everything else is straightforward from here.  The code you wished to reuse
is in "play", hidden behind an abstraction barrier so the compiler may
ensure that it is reused (because there is no other way to play a Game).
State monads don't even enter the picture at this level.

(The return type of Play is Game -> (Bool, Game), which is State Game
Bool... but I would just choose not to notice that; the state structure
isn't important enough here to formalize).

Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090623/d3b00dff/attachment.html


More information about the Haskell-Cafe mailing list