This document discusses designing abstract typeclasses to future-proof typeclass hierarchies against breaking changes. It proposes making typeclass methods hidden, similar to abstract data types, so that typeclass implementations can change without breaking client code. It presents an example using the KnownNat typeclass. It also describes using DerivingVia to write instances for abstract typeclasses by providing a public wrapper class with the same methods. This allows instances to be written while avoiding exposure to potential private changes in the abstract class.

1. ABSTRACT TYPECLASSES
— HOW TO DESIGN A
FUTURE-PROOF TYPECLASS
@mod_poppo
2019-11-09

2. CHANGES TO TYPECLASSES
• Functor-Applicative-Monad
• Semigroup-Monoid
• MonadFail

3. MIGRATION IS PAINFUL
• Adding a superclass
• data Foo a = …
instance Monad Foo where …
-- No instance for Applicative Foo
• Removing a method
• instance Monad Foo where …
fail x = …
-- 'fail' is not a (visible) method of class
'Monad'
• Sometimes #ifdef s cannot be avoided 😵

4. ABSTRACT TYPECLASS
• A data type whose constructors are hidden is abstract
• data Foo = {- hidden -}
• A similar concept could be employed to type classes: A type class
whose methods are hidden
• class Foo a where {- hidden -}

5. AN EXAMPLE OF ABSTRACT TYPECLASS
• An example of abstract
typeclass is
GHC.TypeLits.KnownN
at
• Its method natSing is
hidden
• The user can use this
class via
natVal :: KnownNat
n => proxy n ->
Integer

6. THE MERIT OF BEING ABSTRACT
• The author of the class can freely change the definition of the
class
• e.g. KnownNat has changed its representation since GHC 8.2
(Integer → Natural)
• The user doesn't need to care if its representation changed, as
long as natVal doesn't change

7. MAKING ‘Monad’ CLASS ABSTRACT
• module MyMonad (MyMonad, (>>=), return, fail)
where
• class MyMonad m where
-- the methods are not exported!
bind :: m a -> (a -> m b) -> m b
return_ :: a -> m a
fail_ :: String -> m a
• (>>=) :: MyMonad m => m a -> (a -> m b) -> m b
(>>=) = bind
return :: MyMonad m => a -> m a
return = return_
fail :: MyMonad m => String -> m a
fail = fail_

8. THE PROBLEM WITH ABSTRACT TYPECLASSES
• newtype Foo a = …
instance MyMonad Foo where
{- … what can I write here? 🤔 -}
• Third-party cannot write instances of such classes…
• …without using
• default definitions
• GeneralizedNewtypeDeriving
• …and yes, DerivingVia 😎

9. USING DerivingVia TO WRITE INSTANCES
• module MyMonad (…, MyMonadV1(..), ImplV1(..)) where
• class MyMonad m where …
• class MyMonadV1 m where
-- public!
bindV1 :: m a -> (a -> m b) -> m b
returnV1 :: a -> m a
failV1 :: String -> m a
failV1 = error
• newtype ImplV1 m a = ImplV1 (m a)
• instance MyMonadV1 m => MyMonad (ImplV1 m) where
-- hypothetical code; needs InstanceSigs to work
bind = coerce (bindV1 @m)
return_ = coerce (returnV1 @m)
fail_ = coerce (failV1 @m)

10. USING DerivingVia TO WRITE INSTANCES
• Want to write an instance of MyMonad? Use DerivingVia!
• import MyMonad
• newtype Identity a = Identity a
deriving MyMonad
via ImplV1 Identity
• instance MyMonadV1 Identity where
bindV1 (Identity x) f = f x
returnV1 x = Identity x

11. CHANGING THE CLASS HIERARCHY
• Now suppose you want to refactor MyMonad class
• class Applicative m => MyMonad m where
bind :: m a -> (a -> m b) -> m b
• class MyMonad m => MyMonadFail m where
fail_ :: String -> m a
• Can we avoid breakage?

12. BREAKAGE CAN BE AVOIDED
• …if we change ImplV1's instances accordingly!
• MyMonadV1 is kept as is!
• instance MyMonadV1 m => Functor (ImplV1 m) where …
instance MyMonadV1 m => Applicative (ImplV1 m) where …
instance MyMonadV1 m => MyMonad (ImplV1 m) where …
instance MyMonadV1 m => MyMonadFail (ImplV1 m) where …
• -- a dirty hack is needed (unfortunately)
instance {-# OVERLAPPABLE #-} MyMonadV1 m => Functor m
where
fmap = liftM
instance {-# OVERLAPPABLE #-} MyMonadV1 m =>
Applicative m where
pure = returnV1; (<*>) = ap

13. WHEN TO USE THIS TECHNIQUE?
• When writing a new library
• When you are sure that you would want to change details in the future
• My library unboxing-vector uses a technique similar to this:
• class … => Unboxable a where
type Rep a
-- hidden methods:
unboxingFrom :: a -> Rep a
unboxingTo :: Rep a -> a
• Users can use a newtype wrapper to derive an instance of
Unboxable with Generic

14. I'LL WRITE MORE DETAILS
IN A BLOG (HOPEFULLY
SOON…)