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-boun...@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
| 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
