Wired-in type class

[Iavor Diatchki]

Hi Joachim,

Examples of classes with built-in features in GHC are `SingI`, used for
type-literals, and `IP`, used to implement implicit parameters.
I am not sure what is the best way to implement class NT (I am just back
from vacation, so I haven't had a chance to catch up on e-mails yet), but
here are some pointers that I've found useful while doing things like that:

First, you'll have to teach GHC about the new class.  As long as it works,
the simplest thing would be to declare the class somewhere in the base
library, and then add an entry for it in prelude/PrelNames.hs.  For
example, take a look at `singIClassName` (the actual class is declared in
GHC.TypeLits in the `base` library). It is important to add the class to
`basicKnownKeyNames`, so that GHC knows that it should use the name you
declared, rather than making up another name.

Once you have a name for the new class, you can add built-in instances for
it.  `SingI` provides a bunch of built-in instances, which is done in
`typecheck/TcInteract.hs`.  The actual instances are in function
`matchClassInst`, where we take a look at the name of the class and the its
type parameters, and if everything is as expected, then we create some
evidence (i.e., a kind of dictionary for it).  The exact shape of the
evidence depends on the class method, but `makeDict` in the same function
may give you an idea of what to do in your particular case.  If the
evidence needs to be more complex (i.e., you need to generate an
implementation in Core, Simon showed me another trick involving rules,
which is a bit of a hack, but does seem to work, so I could show you what I
did there too, so just ask).

Hope this helps,
-Iavor
















On Fri, Aug 16, 2013 at 6:43 AM, Joachim Breitner
<mail at joachim-breitner.de>wrote:

> Dear List,
>
> I have some questions about the inner parts of GHC, where I need to
> learn a lot. This is related to my attempts on newtype casting, but
> should probably be kept separate from the conceptual discussions.
>
> Say I need to create a wired-in type class, because it cannot be
> represented in Haskell. The Core type constructor that will come out of
> it will have one field of type ~R#, which is the reason why I cannot
> write it in Haskell.
>
> It seems that defining something wired-in is not a very local operation
> that affects, at least primops.txt.pp and TysPrim.lhs. Does it affect
> more?
>
> It seems that there is not precedent of a wired-in type class. Is that
> possible without touching too many parts of the compiler?
>
> Or is it saner to just have "class NT a b" in a module in ghc-prim
> without the constraint and use special magic when compiling that file to
> add the required field to the data constructor representing the class?
> (Similar to how the kind of ~ is adjusted during compilation?)
>
> Greetings,
> Joachim
>
>
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de • http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0x4743206C
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130816/61fe5f34/attachment.htm>