On Tue, Jun 23, 2009 at 6:05 PM, Eric Dedieu <span dir="ltr">&lt;<a href="mailto:papa.eric@free.fr">papa.eric@free.fr</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Now, trying to avoid duplicate code at this very level of simplicity<br>
seems to require compiler extensions! Here it is:</blockquote><div><br>On a higher level, in case you are interested, here&#39;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...<br>
<br>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&#39;ll keep it concrete for expository purposes:  For example:<br>
<br>newtype Game = MkGame [Char]<br><br>empty :: Game<br>empty = MkGame []<br><br>play :: Char -&gt; Game -&gt; (Bool, Game)<br>play x (MkGame mvs) = (x `elem` moves, MkGame (x:mvs))<br><br>moves :: Game -&gt; [Char]<br>moves (MkGame mvs) = mvs<br>
<br>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).<br><br>Everything else is straightforward from here.  The code you wished to reuse is in &quot;play&quot;, 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&#39;t even enter the picture at this level.<br>
<br>(The return type of Play is Game -&gt; (Bool, Game), which is State Game Bool... but I would just choose not to notice that; the state structure isn&#39;t important enough here to formalize).<br><br>Luke<br></div></div>