Skip to content

Why fay does not currently support type classes

Adam Bergmark edited this page Jun 25, 2013 · 5 revisions

So type-classes are implemented with a dictionary informed by the type system. See the original type-classes paper for a fuller description.

When you write:

class Read a where
  read :: String -> a
instance Read Int where
  read "42" = 42
foo = read "42" * 2

The naive/proper translation is something like:

data Read a = Read
  { read :: String -> a }
inst_Read_Int = Read
  { read = \"42" -> 42 }
foo = read inst_Read_Int "42" * 2

The step that we cannot perform is the third step, translating read "42" to read inst_Read_Int "42", because we do not know what type read "42" should be return, because we don't have a type checker/type information.

However, some type-classes don't need a dictionary because they have no methods, and so are just used as constraints to add extra safety to polymorphic types. Those you can use.

So what are our options if we wish to support it?

The GHC API is one option, the downsides are that it's undocumented and subject to drastic changes (which probably won't be documented well either). Maintenance might take a lot of time and to support several versions of GHC we need CPP.

The other option is the haskell-suite which will hopefully be more stable than the GHC API, but it has not yet been released and at requires Cabal 1.17 so it's not practical to use it before it's on hackage and there is a new haskell platform release.

See #269 for more information.

That said, type class support is something we really want, and we'll spend time prototyping and evaluating which route we should take.