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 <m...@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 > m...@joachim-breitner.de • http://www.joachim-breitner.de/ > Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C > Debian Developer: nome...@debian.org > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
