Quantified Constraints for Higher-kinded Typeclasses

Question

Suppose I would like to write two Typeclasses. Header:

{-# LANGUAGE QuantifiedConstraints #-}
{-# LANGUAGE UndecidableInstances #-}

import Data.Complex

The first typeclass ExClass was defined as such:

class (forall a. (Monoid (t a))) => ExClass t where
    exFunc :: [t (Complex a)] -> t (Complex a)
    exFunc = mconcat -- the actual function is more complicated
    exFunc2 :: (RealFloat a) => t (Complex a) -> a

I defined it as a higher-kinded typeclass because one of its functions' output type depends on the type of its nested value a. I would also like to have a default implementation for exFunc, but it involves the assumption that t a is a Monoid. Now I would like to write an instance for the following type:

newtype ExType a = ExType a

ExType a is a Monoid only when Num a is true:

instance (Num a) => Semigroup (ExType a) where
    ExType a <> ExType b = ExType (a * b)
instance (Num a) => Monoid (ExType a) where
    mempty = ExType 1

Now I go on to define the typeclass instance for ExClass, specifying the constraint of Num a:

instance (forall a. Num a) => ExClass ExType where
    exFunc2 (ExType a) = magnitude a

The above code will compile with no problem. However, if I were to try to use the implemented function like so:

x = ExType 2 :: ExType (Complex Double)

func = exFunc2 x

I receive the following complaint:

• No instance for (Num a) arising from a use of ‘exFunc2’
  Possible fix: add (Num a) to the context of a quantified context
• In the expression: exFunc2 x
  In an equation for ‘func’: func = exFunc2 x

This also happens when I use a different instance declaration:

instance (forall a. Monoid(ExType a)) => ExClass ExType where
    exFunc2 (ExType a) = magnitude a

Is there a way to make this typeclass work? or am I just not supposed to structure my program like this at all?

I can't write a full answer now, but the constraint `(forall a. Num a)` can never be satisfied, because that requires *all* types to have a `Num` instance, which is clearly not the case (e.g. `Char` doesn't have a `Num` instance). — Noughtmare, Oct 11 '21 at 18:38
It seems that ```forall``` doesn't do what I thought it does. I thought it would be like a superclass declaration but for higher-kinded types. So how exactly does Haskell handle ad-hoc polymorphism for higher-kinded typeclass instances? (e.g. for some type ```T```, it requires ```Ord a => T a``` for it to have ```fmap (a->b) -> T a -> T b```, but I cannot specify ```Ord a``` when I write ```instance Functor f where``` since ```a``` does not appear in the declaration) — w41g87, Oct 11 '21 at 18:58
@w41g87 The `Functor` class specifies that `fmap` can be given **any** function `a -> b`. There's no way for an instance to add the special requirement that `a` and `b` must have `Ord`, because other code might use this inatance via polymorphism, and so not know it's this specific instance that has extra requirements. A *different* class could have constraint parameters that allow this (see danidiaz' answer), but you can't do this in an instance if the class hasn't prepared for it. — Ben, Oct 12 '21 at 09:42

danidiaz · Accepted Answer · 2021-10-12T08:16:30.797

Daniel Wagner has already explained in his answer the problems with the current definition.

It seems that you want ExClass to mean something like "a class of container types that have a special relationship with another class c applied to their elements, and when their elements satisfy c, the containers themselves are monoids".

For example: ExType has a special relationship with Num. When the elements a of ExType satisfy Num, ExType a becomes a Monoid.

(This is already affirmed in ExTypes Monoid instance, but it seems you want to express it with a higher level of abstraction; to have a class for those containers that become monoids in a similar way.)

In Haskell, there are various possible ways to express a relationship between two types—or between a type and a Constraint. Let's use MultiParameterTypeClasses:

{-# LANGUAGE QuantifiedConstraints #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE ConstraintKinds #-}

import Data.Kind (Type, Constraint)
-- This kind signature is not strictly required, but makes things clearer
type ExClass :: (Type -> Constraint) -> (Type -> Type) -> Constraint
class (forall a . c a => Monoid (t a)) => ExClass c t | t -> c where
    exFunc :: c a => [t a] -> t a
    exFunc = mconcat

Notice that ExClass has now two parameters, and that the type f of the container determines (through a functional dependency) the constraint c that is required of the elements of f for f to be a Monoid. c might be different for different fs!

The Semigroup and Monoid instances for ExType don't change. The ExClass instance for ExType would now be:

instance ExClass Num ExType where
    exFunc = mconcat

Putting it to work:

main :: IO ()
main = print $ exFunc [ExType (1::Int), ExType 2]

(I have left out the Complex datatype, which might throw another wrench in the definition.)

I like me some constraint kinds, but would remark that classes like that tend to be _fiddly_ to work with. It's not easy to manipulate, combine, unify different instances. — leftaroundabout, Oct 12 '21 at 08:31
This design doesn't allow you to say that a type has a relationship with two classes; e.g. a newtype wrapper around `Map (ExType a) (ExType a)` might want to connect up with `(Ord a, Num a)`. Having the constraint be the output of an associated type family is a bit nicer in that regard. — Daniel Wagner, Oct 12 '21 at 14:20

score 2 · Answer 2 · answered Oct 11 '21 at 23:21

I think there's a couple reasoning errors going on here at once.

First: when you write

class (forall a. Monoid (t a)) => ExClass t

this means that if somebody wants to implement an ExClass t instance, then they must show that there is an instance of the form instance Monoid (t a) where ... with no constraints whatsoever on a. Note also that it is not enough for there to be instances for all possible choices of a -- the instance itself must be parametric.

Second: when you write

instance (forall a. Num a) => ExClass ExType

there is no magical connection between the a mentioned here and the a mentioned in the definition of ExClass.

Third: when you write

instance (forall a. Num a) => ExClass ExType

this doesn't actually make an instance of ExClass ExType yet. It makes an instance conditioned on a proof that forall a. Num a. In general, the meaning of instance Ctx => C t is that anybody who wants to assume the fact C t must be able to themselves prove Ctx. Nobody's going to reasonably be able to show forall a. Num a, so this instance is unusable.

These last two comments apply essentially unchanged to your second attempt,

instance (forall a. Monoid(ExType a)) => ExClass ExType

Unfortunately, without more details on what you're trying to do and why, it's nigh-on impossible to suggest the right route forward. Possibilities include an indexed-monad-like approach, moving the class constraint from the class context to various method contexts, not making a class at all, and more.

So it seems that in Haskell there is no way to put constraints on the content of a higher-kinded typeclass declaration? If I want to write an ```class Exclass f``` where it expects ```f a``` to be a monoid, would I not be able to do that in Haskell? — w41g87, Oct 12 '21 at 00:47
@w41g87 You can instantiate `ExClass` for types `F` who have a `Monoid` instance that looks like `instance Monoid (F a)`; such types have "monoidness" that depends only on the properties of `F`, completely independent of whatever `a` is. For example the list monoid works that way. You cannot instantiate `ExClass` for types like `ExType`, whose "monoidness" depends on the properties of their parameter. — Ben, Oct 12 '21 at 09:31
@w41g87 ...and I think the fact that there are now answers for two out of my three suggested approaches (or slight variations) is good evidence that the right way forward is unclear. — Daniel Wagner, Oct 12 '21 at 15:48

leftaroundabout · Answer 3 · 2021-10-12T08:34:12.737

I would also like to have a default implementation for exFunc, but it involves the assumption that t a is a Monoid

You only require Monoid (t a) in order to have a default implementation? That's backwards. If that constraint isn't conceptually required as a superconstraint for ExClass, then it shouldn't be in the class head.

You can still have a default implementation that is more restrictive:

{-# LANGUAGE DefaultSignatures #-}

class ExClass t where
  exFunc :: [t (Complex a)] -> t (Complex a)
  default exFunc :: Monoid (t (Complex a)) => [t (Complex a)] -> t (Complex a)
  exFunc = mconcat
  exFunc = mconcat -- the actual function is more complicated
  exFunc2 :: (RealFloat a) => t (Complex a) -> a

And then simply

instance ExClass ExType where
  exFunc2 (ExType a) = magnitude a

You would still also be able to provide instances that don't fulfill the Monoid constraint at all, you just then would need to manually implement exFunc too.

Even simpler is to not bother with default implementations at all, but just provide a helper that can be used to get a simple implementation without duplicating any code:

class ExClass t where
  exFunc :: [t (Complex a)] -> t (Complex a)
  exFunc = mconcat -- the actual function is more complicated
  exFunc2 :: (RealFloat a) => t (Complex a) -> a

monoidIshExFunc :: Monoid (t (Complex a)) => [t (Complex a)] -> t (Complex a)
monoidIshExFunc = mconcat

instance ExClass ExType where
  exFunc = monoidIshExFunc
  exFunc2 (ExType a) = magnitude a

(monoidIshExFunc could even require ExClass t, just obviously you should be careful to not end up in a circular definition!)

The constraint ```Monoid (t a)``` is conceptually a superconstraint of ```Exclass```. It is just that ```Monoid (t a)``` can only be satisfied when ```Num a``` is satisfied. — w41g87, Oct 12 '21 at 16:29
Are you sure you're not actually looking for [`VectorSpace`](https://hackage.haskell.org/package/vector-space-0.16/docs/Data-VectorSpace.html)? — leftaroundabout, Oct 12 '21 at 16:33
I am looking for something that performs more comprehensive actions than that. — w41g87, Oct 12 '21 at 18:10

Quantified Constraints for Higher-kinded Typeclasses

3 Answers3