Resolving ambiguity in MultiParameterTypeClass - haskell

Question

Based on the feedback to this question, I've used a MultiParamTypeClass to represent a reinforcement learning environment Environment, using 3 type variables: e for the environment instance itself (e.g. a game like Nim, below), s for the state data type used by the specific game, and a for the action data type used by the specific game.
{-# LANGUAGE MultiParamTypeClasses #-}
class MultiAgentEnvironment e s a where
baseState :: e -> s
nextState :: e -> s -> a -> s
reward :: (Num r) => e -> s -> a -> [r]
data Game = Game { players :: Int
, initial_piles :: [Int]
} deriving (Show)
data State = State { player :: Int
, piles :: [Int]} deriving (Show)
data Action = Action { removed :: [Int]} deriving (Show)
instance MultiAgentEnvironment Game State Action where
baseState game = State{player=0, piles=initial_piles game}
nextState game state action = State{player=player state + 1 `mod` players game,
piles=zipWith (-) (piles state) (removed action)}
reward game state action = [0, 0]
newGame :: Int -> [Int] -> Game
newGame players piles = Game{players=players, initial_piles=piles}
main = do
print "Hello, world!"
let game = newGame 2 [3,4,5]
print game
As expected, I'm running into ambiguity issues already. See below, where the action type variable a is deemed ambiguous within the typeclass Environment.
(base) randm#soundgarden:~/Projects/games/src/Main$ ghc -o basic basic.hs
[1 of 1] Compiling Main ( basic.hs, basic.o )
basic.hs:4:5: error:
• Could not deduce (MultiAgentEnvironment e s a0)
from the context: MultiAgentEnvironment e s a
bound by the type signature for:
baseState :: forall e s a. MultiAgentEnvironment e s a => e -> s
at basic.hs:4:5-23
The type variable ‘a0’ is ambiguous
• In the ambiguity check for ‘baseState’
To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
When checking the class method:
baseState :: forall e s a. MultiAgentEnvironment e s a => e -> s
In the class declaration for ‘MultiAgentEnvironment’
|
4 | baseState :: e -> s
| ^^^^^^^^^^^^^^^^^^^
How do I resolve this ambiguity? Am I mistakenly using typeclasses to implement interfaces (i.e. baseState, nextState, reward)?

Answer 1

While you could turn on AllowAmbiguousTypes, that will only push your problem further down the road. That is, eventually, you'll try to call baseState, and GHC will need to know what a is. There are three good options you have:
Use functional dependencies,
Use associated type families, or
Don't use a class for this.
Let's look at each option in detail.
Functional Dependencies
The problem that GHC is having is that it knows which e and s you want to use when you call a function like baseState (it can determine those from the input and output of the baseState function), but it doesn't know which a to use. For all GHC knows, there may be multiple instantiations of MultiAgentEnvironment that could work for a given e and s. With functional dependencies, you can tell GHC that a given e and s totally define what the a should be. In plain English, by putting in a functional dependency on a, you're saying that for any given environment and state, there is only one possible action type that makes sense. If this is true, then you add them like so:
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FunctionalDependencies #-}
class MultiAgentEnvironment e s a | e s -> a where
baseState :: e -> s
nextState :: e -> s -> a -> s
reward :: (Num r) => e -> s -> a -> [r]
Since each one of your functions have e and s in them, a is the only type parameter that could have been ambiguous, and with this fundep, it's not ambiguous anymore. That said, if you know that the environment type determines both the state and action unambiguously (that is, a given environment can only ever have one possible state and action type), then you can use two fundeps to lower the ambiguity even more, as in:
class MultiAgentEnvironment e s a | e -> s a where
Associated Type Families
Functional Dependencies have a bit of a bad reputation, and the more modern alternative is typically to use associated type families. In practice, for your purposes, they work very similarly. Once again, you have to be okay with the environment type determining the action type (and, perhaps, the state type). If so, you write it like this:
{-# LANGUAGE TypeFamilies #-}
class MultiAgentEnvironment e where
type EState e
type EAction e
baseState :: e -> EState e
nextState :: e -> EState e -> a -> EState e
reward :: (Num r) => e -> EState e -> EAction e -> [r]
Then, when you create your instance, it will look like:
instance MultiAgentEnvironment Game where
type EState Game = State
type EAction Game = Action
baseState game = State{player=0, piles=initial_piles game}
nextState game state action = ...
Use a Data Type Instead Of a Class
The last option is to forgo using a type class altogether. Instead, you can make the data explicit by just representing it as a data type. For instance, you can define:
{-# LANGUAGE RankNTypes #-}
data MultiAgentEnvironment e s a = MultiAgentEnvironment
{ baseState :: e -> s
, nextState :: e -> s -> a -> s
, reward :: forall r. (Num r) => e -> s -> a -> [r]
}
Instead of making an instance of the type class, you just make a value of the data type:
gameStateActionMAE :: MultiAgentEnvironment Game State Action
gameStateActionMAE = MultiAgentEnvironment
{ baseState = \game -> State{player=0, piles=initial_piles game}
, nextState = \game state action -> State{player=player state + 1 `mod` players game,
piles=zipWith (-) (piles state) (removed action)}
, reward = \game state action -> [0, 0]
}
One nice advantage of this method is that you can make multiple different MultiAgentEnvironments with the same types but that have different behaviors. Using them is pretty simple too: instead of having MultiAgentEnvironment e s a as a constraint, you now have it as just a regular old argument. In fact, if you turn on the RecordWildCards pragma, then any function that used to start with
foo :: MultiAgentEnvironment e s a => x -> y
foo x = ...
can now be written as
foo :: MultiAgentEnvironment e s a -> x -> y
foo mae#MultiAgentEnvironment{..} x = ...
and the body should be pretty much identical (well, unless the body calls a subfunction which requires the MultiAgentEnvironment, in which case you'll need to manually pass mae along).