Type constraints are ending up ambiguous - haskell

Question

In a Haskell app I'm working on, I have an API in which I'm trying to set up a pluggable set of backends. I'll have several different backend types and I want the caller (right now, just the test suite) to determine the actual backends. However, I'm getting an ambiguous type error.
class HasJobQueue ctx queue where
hasJobQueue :: JobQueue queue => ctx -> queue
class JobQueue q where
enqueue :: MonadIO m => Command -> q -> m ()
type CloisterM ctx queue exc m = ( Monad m, MonadIO m, MonadError exc m, MonadReader ctx m
, AsCloisterExc exc
, HasJobQueue ctx queue
, JobQueue queue
)
createDocument :: forall ctx queue exc m. CloisterM ctx queue exc m => Path -> Document -> m DocumentAddr
createDocument path document = do
...
queue <- hasJobQueue <$> ask
enqueue (SaveDocument addr document) queue
...
So, to me this seems pretty clear. In createDocument, I'm wanting to retrieve the context, and from that retrieve the job queue, which the caller would define and attach to the context. But Haskell disagrees and gives me this error:
• Could not deduce (JobQueue q0)
arising from a use of ‘hasJobQueue’
from the context: CloisterM ctx queue exc m
bound by the type signature for:
createDocument :: CloisterM ctx queue exc m =>
Path -> Document -> m DocumentAddr
at src/LuminescentDreams/CloisterDB.hs:32:1-105
The type variable ‘q0’ is ambiguous
• In the first argument of ‘(<$>)’, namely ‘hasJobQueue’
Here is an example of what I am trying to build, this one from my API test suite where I am mocking all of the backends with simple IORefs, where production will have other backend implementations
data MemoryCloister = MemoryCloister WorkBuffer
newtype WorkBuffer = WorkBuffer (IORef [WorkItem Command])
instance JobQueue WorkBuffer where
hasJobQueue (MemoryCloister wb) = wb
instance JobQueue WorkBuffer where
...
So, what exactly do I need to do to help the type checker understand that the context in the MonadReader contains an object that implements the JobQueue class?
The entire data types file, including how I ultimately reformulated the JobQueue for something more flexible than even the above, is in this project

Answer 1

While it’s difficult to know exactly what the right solution to your problem is based on the code and context given, the error you’re seeing stems from the HasJobQueue typeclass, which is extremely general:
class HasJobQueue ctx queue where
hasJobQueue :: JobQueue queue => ctx -> queue
From the typechecker’s point of view, hasJobQueue is a function from a -> b, plus a few constraints (but constraints do not generally affect type inference). This means that, in order to invoke hasJobQueue, both its input and its output must be entirely unambiguously specified by some other source of type information.
If this this confusing, consider a slightly different class that is nearly identical to the typechecker:
class Convert a b where
convert :: a -> b
This typeclass is generally an antipattern (precisely because it makes type inference very hard), but it could theoretically be used to provide instances to convert between any two types. For example, one could write the following instance:
instance Convert Integer String where
convert = show
…then use convert to convert an integer to a string:
ghci> convert (42 :: Integer) :: String
"42"
However, note that the following will not work:
ghci> convert (42 :: Integer)
<interactive>:26:1: error:
• Ambiguous type variable ‘a0’ arising from a use of ‘print’
prevents the constraint ‘(Show a0)’ from being solved.
Probable fix: use a type annotation to specify what ‘a0’ should be.
The issue here is that GHC has no idea what b should be, so it can’t pick which Convert instance to use.
In your code, hasJobQueue is much the same, though the details are a little more complex. The issue arises in the following lines:
queue <- hasJobQueue <$> ask
enqueue (SaveDocument addr document) queue
In order to know which HasJobQueue instance to use, GHC needs to know the type of queue. Well, fortunately, GHC can infer types for bindings based on how they are used, so hopefully, queue’s type can be inferred. It is provided as the second argument to enqueue, so we can understand what’s going on by looking at the type of enqueue:
enqueue :: (JobQueue q, MonadIO m) => Command -> q -> m ()
And here we see the problem. The second argument of enqueue must have type q, which is also unconstrained, so GHC does not gain any additional information. Therefore, it can’t determine the type of q, and it doesn’t know which instance to use for either the call to hasJobQueue or the call to enqueue.
So how can you solve this? Well, one way would be to pick a particular type for queue, but based on your code, I’m betting that isn’t actually what you want. More likely, there is a particular type of queue associated with each particular ctx, so the return type of hasJobQueue should really be implied by its first argument. Fortunately, Haskell has a notion to encode this very thing, and that notion is functional dependencies.
Remember that I said at the beginning that constraints do not generally affect type inference? Functional dependencies change that. When you write a fundep, you state that the typechecker actually can gain information from a constraint because some of the type variables imply some of the others. In this case, you want queue to be implied by ctx, so you can change the definition of HasJobQueue:
class HasJobQueue ctx queue | ctx -> queue where
hasJobQueue :: JobQueue queue => ctx -> queue
The | ctx -> queue syntax can be read as “ctx implies queue”.
Now, when you write hasJobQueue <$> ask, GHC already knows ctx, and it knows it can figure out queue from ctx. Therefore, the code is no longer ambiguous, and it can pick the correct instances.
Of course, nothing is for free. The functional dependency is nice, but what do we give up? Well, it means we promise that, for each ctx, there is exactly one queue, no more. Without the functional dependency, both of these instances can coexist:
instance HasJobQueue FooCtx MyQueueA
instance HasJobQueue FooCtx MyQueueB
These are totally legal, and GHC will pick the instance based on which type of queue is requested by the calling code. With the functional dependency, this is illegal, which makes sense—the whole point is that the second parameter must be implied by the first, and if two different options are possible, GHC can’t disambiguate by the first parameter alone.
In this sense, functional dependencies allow typeclass constraints to have “input” and “output” parameters. Sometimes, functional dependencies are called “type-level Prolog”, since they turn the constraint solver into a relational sublanguage. This is extremely powerful, and you can even write classes with bidirectional relations:
class Add a b c | a b -> c, a c -> b, b c -> a
Usually, though, most uses of functional dependencies involve cases like the one you ran into, where one structure semantically “has” an associated type. For example, one of the classic examples come from the mtl library, which use functional dependencies to represent reader context, writer state, etc.:
class MonadReader r m | m -> r
class MonadWriter w m | m -> w
class MonadState s m | m -> s
class MonadError e m | m -> e
This means they can be equivalently expressed in a slightly different way using associated types (part of the TypeFamilies extension)… but that is probably outside the scope of this answer.