ハスケル - 何度も同じ文脈を繰り返すのを避けるには？

Question

私は最近少し遅れてhobby projectを開始しました。ここでは、トリックプレイのカードゲームSkat（3人のプレイヤー）を実装しようとしています。

class Monad m => Player p m | p -> m where 
    playerMessage :: Message answer -> p -> m (Either Error answer,p) 

が、私はこれらの3人のプレーヤーをラップする StateTを使用します：

一緒に遊ん（AI、ネットワークおよびローカルのような）選手の異なる種類を持っていることを可能にするために、私は型クラス Playerを使用して interfaceをデザイン

type PST a b c m x = StateT (Players a b c) m x 

しかし、今、私はそれぞれの型シグネチャにコンテキストの大きな山を記述する必要があります。

dealCards :: (Player a m, Player b m, Player c m, RandomGen g) 
    => g -> PST a b c m (SomeOtherState,g) 

がどのように回避することができますこの大きな文脈を何度も繰り返し書いていますか？

Answer 1

• あなたがプレイヤークラスから観察することができる唯一のことは、

  playerMessage' :: Message answer -> m (Either Error answer, p) 
  

  したがってタイプの関数であり、 、あなたは完全にクラスを排除し、これは基本的にmy previous answerある

  data Player m = Player { playerMessage' 
         :: Message answer -> m (Either Error answer, Player m) } 
  

  通常のデータ型を使用することができます。

• 代わりの方法は、GADTを使用してコンテキストをデータ型に移動することです。

  data PST a b c m x where 
      PST :: (Player a m, Player b m, Player c m) 
       => StateT (Players a b c) m x -> PST a b c m x 
  

  つまり、制約はデータ型の一部になります。

• 私の意見では、TicTacToe exampleの行に沿って全体をスクラップし、operational packageから再設計するのが最善の解決策です。このデザインでは、各プレイヤー（人、AI、リプレイなど）を特殊なモナドに書き込んだり、後ですべてを共通のインタプリタに注入することができます。

Answer 2

アップデート：私はdealCardsを実装しようとしたとき 私は私の解決策は、選手たちは交換することによって、型の安全性を減少させることを実現しています。この方法で、一方のプレイヤーをもう一方のプレイヤーの代わりに簡単に使用できます。これは望ましくない可能性があります。

---

あなたがExistentialQuantificationを使用して気にしない場合、私はそれができると思う（とすべきでは？）ここで使用されます。結局のところ、dealCards関数は、a、b、cについて気にするべきではありません。

{-# LANGUAGE ExistentialQuantification #-} 
{-# LANGUAGE MultiParamTypeClasses #-} 
{-# LANGUAGE FunctionalDependencies #-} 

import Control.Monad.State 
import System.Random 

type Message answer = answer 
type Error = String 

class Monad m => Player p m | p -> m where 
    playerMessage :: Message answer -> p -> m (Either Error answer,p) 

data SomePlayer m = forall p. Player p m => SomePlayer p 

data Players m = Players (SomePlayer m) (SomePlayer m) (SomePlayer m) 

type PST m x = StateT (Players m) m x 

dealCards :: (RandomGen g, Monad m) => g -> PST m x 
dealCards = undefined 

私は同様の方法でMonad制約を排除することが可能であるべきだと思います。

実際、このような場合、タイプクラスが過度に使用されているように感じます。たぶんそれは私に話してHaskellの初心者ですが、私が代わりにこれを記述します

data Player m = Player { playerMessage :: Message answer -> m (Either Error answer, Player m) } 

Answer 3

明らかに、より良い答えは、最初にすべてのタイプパラメータを必要としないデザインを持つことです。

class (Storable.Storable (X, y), Y y) => Signal y 

今書い「（信号y）=> ...」します：あなたが実際にそれらを取り除くことができない、と提起としての質問に答えるためにしかし、もし、ここで私がプレイしたトリックですすべての他のタイプメスを暗示し、Storableのような実装の詳細がすべてのAPIに入るのを防ぐ。ただし、Signalのインスタンスを宣言する必要があります。メソッドを持たないので簡単ですが、ほとんどインスタンスがなくても多くの機能がある場合に最適です。