You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.