Wired-in type class

Simon Peyton-Jones simonpj at microsoft.com
Sun Aug 18 17:24:46 CEST 2013


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 at 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 at joachim-breitner.dehttp://www.joachim-breitner.de/
|    Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0x4743206C
|    Debian Developer: nomeata at debian.org


More information about the ghc-devs mailing list