Defining instance with a type synonym

Question

Apologies if this has been asked/answered many times over already -- I am having a hard time formulating what the problem actually is and thus didn't really know what to search for.

---

Essentially, I have a class I have defined such that :

class (MonadIO m) => Logger m where ...

And then I have a type (I want to say type synonym but I am not sure if this is the right 'term' ) :

type ResourceOpT r m a = StateT (ResourceCache r) m a

---

Why is it that this instance is perfectly valid :

instance (MonadIO m) => Logger ( StateT s m )

But not this one (I guess the first one is more abstract/preferrable but I'm trying to understand why) :

instance (MonadIO m) => Logger ( ResourceOpT r m )

Shouldn't both be equivalent by virtue of how I have defined ResourceOpT? Specifically, the error I am getting is :

  The type synonym 'ResourceOpT' should have 3 arguments, but has been given 2
  In the instance declaration for 'Logger (ResourceOpT r m)'

I have a feeling what I am doing 'should' conceptually work but either my syntax is wrong or there is something (maybe a language extension) that I am missing or should be enabling for this to work.

Regardless, I would be interested to get your input and learn why this is wrong and also why I should/should not be doing that.

Thanks in advance.

Answer 1

The error reads:

The type synonym ResourceOpT should have 3 arguments

A type synonym (defined with type; you have the right term!) must be applied to the same number of type arguments as the number of parameters in its definition. That is, it’s sort of a “macro” for types, which is just substituted with its definition; it can’t be partially applied like a function can. In your case, ResourceOpT demands three arguments:

type ResourceOpT r m a = StateT (ResourceCache r) m a
              -- ^ ^ ^

This restriction makes it possible to do type inference with higher-kinded types, that is, things that abstract over type constructors like Monad and Foldable. Allowing type synonyms to be partially applied would mean that the compiler couldn’t deduce things like (m Int = Either String a) ⇒ (m = Either String, a = Int).

There are a few solutions. One is to start by directly addressing what the compiler is talking about, and change the number of parameters in the definition of ResourceOpT:

type ResourceOpT r m = StateT (ResourceCache r) m
              --    ^ ---------- no ‘a’ ----------^

Then, entering this code:

instance (MonadIO m) => Logger ( ResourceOpT s m )

Produces this different message:

Illegal instance declaration for Logger (ResourceOpT s m)

(All instance types must be of the form (T t1 ... tn) where T is not a synonym. Use TypeSynonymInstances if you want to disable this.)

If you use the -XTypeSynonymInstances compiler flag or {-# LANGUAGE TypeSynonymInstances #-} pragma in a source file, it allows making an instance for the type that a synonym expands to. This produces yet another message:

Illegal instance declaration for Logger (ResourceOpT s m) (All instance types must be of the form (T a1 ... an) where a1 ... an are distinct type variables, and each type variable appears at most once in the instance head. Use FlexibleInstances if you want to disable this.)

FlexibleInstances relaxes some restrictions on instances you can make. It shows up pretty often when writing certain kinds of code with monad transformers. Adding it, this code is accepted. What you’ve done here is make an instance of your Logger class for StateT s m for all s and m, provided that m is in MonadIO. If anyone wants to make a Logger instance for a different specialisation of StateT to something other than ResourceCache, then it will be rejected, or they’ll have to jump through some dubious hoops with overlapping instances.

One alternative that doesn’t require these extensions is to make a newtype instead of a type synonym:

newtype ResourceOpT r m a = ResourceOpT
  { getResourceOpT :: StateT (ResourceCache r) m a }

A newtype is, well, a new type, not a synonym. In particular, it’s a zero-cost wrapper for another type: same representation but different typeclass instances.

Doing this, you can write or derive instances of Applicative, Functor, Monad, MonadIO, MonadState (ResourceCache r), and so on, for the concrete type constructor ResourceOpT, just like all the other transformers in transformers like StateT, ReaderT, and so on. You can also partially apply the ResourceOpT constructor, because it’s not a type synonym.

And in general, the reason to have a Logger class is that you want to write code generic in the type of logger, because you have multiple different types that could be instances. But especially if ResourceOpT is the only one, then you can also do away with the class and write code in the concrete ResourceOpT, or a polymorphic m with a constraint such as MonadState (ResourceCache r) m. In general, a function parameter or polymorphic function is preferable to adding a new typeclass; however, without the details of the class definition and use case, it’s hard to say whether & how yours ought to be refactored.

Answer 2

As you stated before, the type ResourceOpT has three arguments type ResourceOpT r m a. The kind of a type constructor is "the type of the type". We can say that ResourceOpT's kind is * -> * -> * -> *.

But you are only giving it two parameters when you use it below instancing it. So Haskell it's complaining.

In other words, if we apply the two parameters that are given, we have an expression of kind * -> *, while Logger m receives something of kind *, as Logger is of kind * -> *.

In short, you have to give it three arguments instead of two

For more info, you can see Haskell Wiki for kind https://wiki.haskell.org/Kind

Answer 3

Haskell type synonyms are sort of like macros or abbreviations at the type level. The idea is that if you declare a type synonym like

type T a b c = ...

then wherever the type T x y z appears, GHC will internally rewrite it to the ..., with x, y, and z substituted for a, b, and c.

This substitution is fairly stupid and mechanical, so GHC doesn’t allow type synonyms to be partially applied. That is, you can’t have a type like T x y because it can’t be expanded to the ... without a third type argument. Therefore, type synonyms have to be fully saturated—that is, fully applied to arguments—wherever they appear.

Like the definition of T above, your ResourceOpT type synonym is declared to accept three arguments, but in your instance declaration, you’ve only applied it to two. This is why GHC complains. The same restriction does not apply to StateT because StateT is not a type synonym declared with type, it is a fully-fledged type in its own right declared with newtype, so it suffers no such restrictions.

There are two ways to resolve this problem:

1. Reduce the number of type arguments your type family accepts.

   Since Haskell’s type system is higher-kinded, you can define your ResourceOpT type with only one argument, like this:

   type ResourceOpT r = StateT (ResourceCache r)
   

   This definition is equivalent, since ResourceOpT r m a will still expand into StateT (ResourceCache r) m a; the right-hand side of the ResourceOpT definition is simply partially applied. Removing arguments this way is known more generally as eta reduction, and it is usually a good idea when defining type synonyms for precisely the reasons given above.

2. Use a newtype declaration instead of a type synonym:

   newtype ResourceOpT r m a = ResourceOpT (StateT (ResourceCache r) m a)
   

   This is more work, since it defines a separate wrapper type rather than a type alias, but it is often preferable to using a type synonym when the intent is to define new typeclass instances on your new type.

   The reason for this is that typeclass instances on type synonyms will always conflict with typeclass instances declared on the base type. That is, in this case, instance Logger (ResourceOpT r m) will conflict with instance Logger (StateT s m). That’s because, again, type synonyms are just abbreviations, and after they’re expanded, there is no difference between the two types, so the two instances necessarily overlap.

Which choice you decide to use here is up to you, but I generally recommend going the newtype route whenever typeclass instances are involved. It’s more work, but it will save you pain later. If you do go that route, you will probably want to look into using GHC’s generalized newtype deriving feature to cut down most of the boilerplate involved when writing newtypes.

Answer 4

After asking on the #haskell IIRC, some kind people did a bit of explaining & linked me to this : https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-730004.2.2

Essentially, and from what I understand (hopefully correctly now), my second example of an instance is attempting to partially apply the type synonym, which is not legal according to Haskell2010 standard.

What I ended up doing was revise my definition of ResourceOpT (in effect making it a partial type constructor by omitting the other two terms):

type ResourceOpT r = StateT (ResourceCache r)

Then the statement below becomes legal (as it synonymous & complete whereas previously it wasn't):

instance (MonadIO m) => Logger (ResourceOpT r m)