Haskell - Jak uniknąć wpisywania tego samego kontekstu w kółko?

Question

Niedawno zacząłem mały hobby project, w którym staram się wprowadzić sztuczną grę w karty Skat (dla 3 graczy). Aby było to możliwe, aby mieć różne rodzaje graczy (jak AI, sieci i lokalnych) gra razem, zaprojektował interface użyciu typeclass Player:

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

używam StateT omotać tych trzech graczy:

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

Ale teraz, muszę napisać wielki stos w kontekście każdego podpisu typu:

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

Jak można uniknąć pisząc ten duży kontekst raz za razem?

Answer 1

• Jedyną rzeczą, jaką można obserwować z klasy gracza jest funkcją typu

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

  Stąd można wyeliminować całkowicie klasę i użyć zwykłej typ danych

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

  jest to w zasadzie my previous answer.

• Alternatywnym rozwiązaniem jest przeniesienie kontekstu do typu danych za pomocą 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 
  

  Innymi słowy, ograniczenia stają się częścią typu danych.

• Najlepszym rozwiązaniem jest, moim zdaniem, złomowanie całej rzeczy i przeprojektowanie jej wzdłuż linii TicTacToe example z mojego operational package. Ten projekt pozwala ci napisać każdego gracza (człowieka, AI, powtórka, ...) w specjalistycznej monadzie, a następnie wstrzyknąć wszystko do zwykłego tłumacza.

Answer 2

Aktualizacja: Kiedy próbowałem wykonawczych dealCards zdałem sobie sprawę, że moje rozwiązanie zmniejsza typu bezpieczeństwa przez co gracze wymienne. W ten sposób możesz łatwo użyć jednego gracza zamiast drugiego, co może być niepożądane.

---

Jeśli nie przeszkadza ExistentialQuantification, myślę, że może (i powinien?) Być tutaj. Przecież funkcja dealCards nie powinna się przejmować ani wiedzieć o tym, czy są one a, b i c, prawda?

{-# 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 

myślę, że powinno być możliwe do wyeliminowania Monad wymuszenie w podobny sposób.

Właściwie w takich przypadkach wydaje mi się, że zajęcia nadrzędne są nadużywane. Może to początkujący Haskell mówienia mnie, ale ja piszę to zamiast:

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

Answer 3

Oczywiście lepszą odpowiedzią jest posiadanie projektu, który nie wymaga wszystkich tych parametrów. Jednakże, jeśli naprawdę nie można się ich pozbyć, i odpowiedzieć na pytanie, jakie, oto sztuczka Grałem:

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

Teraz pisanie „(sygnał y) => ...” będzie implikuj wszystkie inne typologie i nie dopuść do szczegółów implementacji takich jak Storable od wchodzenia w każdy interfejs API. Musisz jednak zadeklarować instancje dla Signal. Jest to łatwe, ponieważ nie ma żadnych metod, ale prawdopodobnie jest najbardziej odpowiedni, gdy masz kilka instancji, ale wiele funkcji.