Associated Parameter Restriction using Functional Dependency

Question

The function f below, for a given type \'a\', takes a parameter of type \'c\'. For different types \'a\', \'c\' is restricted in different ways. Concretely, when \'a\' is any In

Answer 1

Here's a suggestion to solve a more general problem, not yours specifically (I need more detail yet first - I promise to check later). I'm writing it in case other people are searching for a solution to a similar problem to you, I certainly was in the past, before I discovered SO. SO is especially great when it helps you try a radically new approach.

I used to have the work habit:

1. Introduce a multi-parameter type class (Types hanging out all over the place, so...)
2. Introduce functional dependencies (Should tidy it up but then I end up needing...)
3. Add FlexibleInstances (Alarm bells start ringing. There's a reason the compiler has this off by default...)
4. Add UndecidableInstances (GHC is telling you you're on your own, because it's not convinced it's up to the challenge you're setting it.)
5. Everything blows up. Refactor somehow.

Then I discovered the joys of type families (functional programming for types (hooray) - multi-parameter type classes are (a bit like) logic programming for types). My workflow changed to:

1. Introduce a type class including an associated type, i.e. replace

   class MyProblematicClass a b | a -> b where
     thing :: a -> b
     thang :: b -> a -> b
   

   with

   class MyJustWorksClass a where
     type Thing a :: * -- Thing a is a type (*), not a type constructor (* -> *)
     thing :: a -> Thing a
     thang :: Thing a -> a -> Thing a
   

2. Nervously add FlexibleInstances. Nothing goes wrong at all.

3. Sometimes fix things by using constraints like (MyJustWorksClass j,j~a)=> instead of (MyJustWorksClass a)=> or (Show t,t ~ Thing a,...)=> instead of (Show (Thing a),...) => to help ghc out. (~ essentially means 'is the same type as')
4. Nervously add FlexibleContexts. Nothing goes wrong at all.
5. Everything works.

The reason "Nothing goes wrong at all" is that ghc calculates the type Thing a using my type function Thang rather than trying to deduce it using a merely a bunch of assertions that there's a function there and it ought to be able to work it out.

Give it a go! Read Fun with Type Functions before reading the manual!

Answer 2

OK, this one's been nagging at me. given the wide variety of instances, let's go the whole hog and get rid of any relationship between the source and target type other than the presence of an instance:

{-# LANGUAGE OverlappingInstances, FlexibleInstances,TypeSynonymInstances,MultiParamTypeClasses #-}

class Foo a b where f :: a -> b

Now we can match up pairs of types with an f between them however we like, for example:

instance Foo Int Int where f = (+1)
instance Foo Int Integer where f = toInteger.((7::Int) -)
instance Foo Integer Int where f = fromInteger.(^ (2::Integer))
instance Foo Integer Integer where f = (*100)
instance Foo Char Char where f = id
instance Foo Char String where f = (:[])  -- requires TypeSynonymInstances
instance (Foo a b,Functor f) => Foo (f a) (f b) where f = fmap f -- requires FlexibleInstances
instance Foo Float Int where f = round
instance Foo Integer Char where f n = head $ show n

This does mean a lot of explicit type annotation to avoid No instance for... and Ambiguous type error messages. For example, you can't do main = print (f 6), but you can do main = print (f (6::Int)::Int)

You could list all of the instances with the standard types that you want, which could lead to an awful lot of repetition, our you could light the blue touchpaper and do:

instance Integral i => Foo Double i where f = round -- requires FlexibleInstances
instance Real r => Foo Integer r where f = fromInteger -- requires FlexibleInstances

Beware: this does not mean "Hey, if you've got an integral type i, you can have an instance Foo Double i for free using this handy round function", it means: "every time you have any type i, it's definitely an instance Foo Double i. By the way, I'm using round for this, so unless your type i is Integral, we're going to fall out." That's a big issue for the Foo Integer Char instance, for example.

This can easily break your other instances, so if you now type f (5::Integer) :: Integer you get

Overlapping instances for Foo Integer Integer
  arising from a use of `f'
Matching instances:
  instance Foo Integer Integer
  instance Real r => Foo Integer r

You can change your pragmas to include OverlappingInstances:

{-# LANGUAGE OverlappingInstances, FlexibleInstances,TypeSynonymInstances,MultiParamTypeClasses #-}

So now f (5::Integer) :: Integer returns 500, so clearly it's using the more specific Foo Integer Integer instance.

I think this sort of approach might work for you, defining many instances by hand, carefully considering when to go completely wild making instances out of standard type classes. (Alternatively, there aren't all that many standard types, and as we all know, notMany choose 2 = notIntractablyMany, so you could just list them all.)

Answer 3

A possibly better way, is to use constraint kinds and type families (GHC extensions, requires GHC 7.4, I think). This allows you to specify the constraint as part of the class instance.

{-# LANGUAGE ConstraintKinds, TypeFamilies, FlexibleInstances, UndecidableInstances #-}

import GHC.Exts (Constraint)

class Foo a where
   type ParamConstraint a b :: Constraint
   f :: ParamConstraint a b => b -> a

instance Integral i => Foo i where
   type ParamConstraint i b = Real b
   f = fIntegral

_{EDIT: Upon further experimentation, there are some subtleties that mean that this doesn't work as expected, specifically, type ParamConstraint i b = Real b is too general. I don't know a solution (or if one exists) right now.}