>>262
SceneProcはステートマシンとしては普通の定義だと思う。

>やたら if や case of で場合分けする羽目になるということ。
そういう風に定義する計算モデルなのだから致し方ない。
ステートマシンを状態遷移表で書き下したとき、

・titleSceneやoptionScene等の関数が「状態」
・パターンやガードが「入力」
・その右辺式の値が「出力と遷移」 (ScreenDesc, SceneProc)

に対応していて、ミーリー型オートマトンを定義してる、と考えるといいと思う。
Monadiusの定義だとムーア型かな。
シーンを関数として作る、というのは方向性として間違ってないんじゃないかな。
各シーンの内部状態をさらにどうしてるかが問題だけど。
IORefを多用している事と、ステートマシンが分岐だらけであることとはあまり関連性がない気がする。

とりあえずステートマシンの参考になりそうな、有名所を適当に上げると、、
SceneProcの定義はYampaの定義が一番近いと思う。Netwireも確かこんなん。
これらの単純なモデルは、arrowsパッケージのAutomaton i o。（関数型プログラミングの楽しみ10章の単純オートマトン）

変種としては、
SceneProc r
　= SP (Time -> GamePad -> (ScreenDesc, SceneProc r))
　|　Done r
と、Done rを付け加えるとモナドにできて、コルーチンみたいな中断／再開が可能になる。（Done rは受理状態に相当。）
Enumeratorとか、Conduit、Pipes、もこのタイプ。
これらをさらに抽象化したのがmonad-coroutineで、コイツは実はMonadFreeというものに解りやすい名前を付けただけ、
とか色々奥の深い世界があったりする。
MonadFreeの別の応用としてOperationalモナドというのもあったり…。（自動モナド化とか、インタプリタとか興味深かった）