MonadIO Type Constraint about objectname HOT 1 CLOSED

Let's consider an extremely simple example:

data Foo = Foo

isFoo :: Foo -> IO Bool
isFoo _ = return True

deleteFoo :: Foo -> IO ()
deleteFoo _ = return ()

So Foo is a name for some kind of objects, and its related predicate and its deletion function live in the IO monad, something which e.g. is the common case for OpenGL-related names. Now assume that following your proposal ObjectName uses Monad m instead of MonadIO m. Then the following will not type-check:

instance ObjectName Foo where
  isObjectName = isFoo
  deleteObjectName = deleteFoo

The reason for this is that isFoo has a more specific type than isObjectName requires: isFoo only works for IO, not for all monads. BTW: This has nothing to do with the fact that isObject name is part of a class, the same type-checking error would happen everywhere a type signature is more general than the principal type of the value it refers to: [True] :: [a] is wrong, while e.g. [] :: [Int] is OK. Remember that all free type variables are universally quantified, include the type variables in contexts.

The current context MonadIO m is a bit more specific than plain Monad m, the former requires a monad in which IO actions can be embedded. This way, one can easily make Foo an instance of ObjectName:

instance ObjectName Foo where
  isObjectName = liftIO . isFoo
  deleteObjectName = liftIO . deleteFoo

In a nutshell: With your proposal one would have a hard time making any sensible instances at all, because things would have to work for all monads. With multi-parameter type classes and functional dependencies you can achieve what you want, but that's not what ObjectName is for.

from objectname.