Joachim I've been thinking about this a bit. I think for you the best path may be this: * Make NT a wired-in Class. We don't have any of these at the moment, but there should be no difficulty in creating one, along the lines of the wired-in TyCons in TysWiredIn. Its data con should have the type NT :: (a ~R# b) -> NT a b * Also make ntCast a wired-in It (see example in MkId), with an unfolding like ntCast :: NT a b => a -> b ntCast = /\ab. \d:NT a b. \x:a. case d of NT (g : a ~R# b) -> x |> g * In the base module, define NT as a data type, and ntCast as a function: data NT a b where NT :: NT a a ntCast :: NT a b -> a -> b ntCast NT x = x These definitions will never get imported, because the definitions are wired-in. And indeed they are slightly wrong: we are declaring NT as a data type not a class, and the type of NT will be NT :: (a ~T# b) -> NT a b But they may still be used if, for example, we say (map ntCast xs). All that matters is that their execution behaviour is correct, which it will be. * We are only going to allow GHC-derived instances of NT. The instance for NT a a may be super-special: as Iavor mentions we can check for that specially in matchInst. All the others are generated by a 'deriving' clause. Happy to discuss. There is probably too much to do, and get settled, for it to be in 7.8 anyway. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Joachim | Breitner | Sent: 16 August 2013 20:54 | To: ghc-devs | Subject: Re: Wired-in type class | | Hi, | | thanks for your pointers, they are very helpful. The problem is that one way of | implementing NT involves a class declaration (not just instances) that I cannot | write in Haskell. I tried to completely generate the the class in GHC.Prim, without | corresponding source, but that failed (e.g. | that module has mi_decl = []; I took that as a sign that I’m not on the right | track). | | So I am back at generating a TypeCon in GHC.Prim which (to Haskell | abstractly) contains the non-Haskell-fields and then have a simple class with one | member of that type. Semantically all the same, and easier implementation. | | | Am Freitag, den 16.08.2013, 10:25 -0700 schrieb Iavor Diatchki: | | > 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). | | In my case, I’d like to generate instances when the users asks for it via derving | clauses; but there as well I have the issue that deriving stuff happens before | desugaring, but the implementation will have to be in Core. So I’m very much | interested in the trick. | | Greetings, | Joachim | | -- | Joachim “nomeata” Breitner | mail@joachim-breitner.de • http://www.joachim-breitner.de/ | Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C | Debian Developer: nomeata@debian.org