Pedro Hmm. I suggest you address me, but cc cvs-ghc. For fine details we can drop cvs-ghc to avoid spam, but I expect they'll be happy to know what's going on. [cvs-ghc'ers, Pedro is implementing his 2010 Haskell Symposium paper "A generic deriving mechanism for Haskell", to replace GHC's existing but hardly-used "derivable type classes". Yell if you don't want us to cc you.]
1) The meta-information classes (which store info like constructor names and arities) use base types like Char and Bool, which are also defined somewhere in ghc-prim. However, those modules need to import GHC.Generics, because they too will have representations. Do we have to make these modules mutually recursive? Well, it seems that the GHC.Generics types are even more primitive than Char and Bool. After all, we need them to make the meta-info for Char and Bool, but the types in GHC.Generics don't themselves have meta-info (or do they?). So it sounds as if GHC.Generics should be in the ghc-prim package. If they use Char and Bool it's probably easiest to put the data type declarations in the same module, GHC.Types. I'm not sure why Bool is declared in a one-line module GHC.Bool, rather than in GHC.Types. Ian? Couldn't it go in GHC.Types? Ian, can you remind us of the rationale for the ghc-prim package? I believe that it exists because we wanted to have a separate package for arbitrary precision integers, integer-gmp. So anything needed by integer-gmp had to be in a simpler package, and that's ghc-prim. Is that right? So why are Float and Double there? 2) The new GHC.Generics is far bigger than the previous, defining many more names. In particular, very basic names like P and S are now "taken". Text.ParserCombinators.ReadP (in base) clashes with this. In base this is easy to fix. But Data.Binary.Get (in binary) also gets a name clash. In general, I assume that the representation types will only be visible if GHC.Base is imported, so this won't be a big problem for user-defined modules. But what to do about all the boot packages? Should we choose more inconspicuous names? It only matters that it uses "P" and "S" if those names are re-exported, and imported by (say) ReadP. So either give them longer names, or refrain from importing GHC.Generics. Simon From: José Pedro Magalhães [mailto:[email protected]] Sent: 13 October 2010 16:08 To: Simon Peyton-Jones Subject: Re: Generic deriving in GHC Hi Simon, So, I replaced the current GHC.Generics with my base module, and two issues arise: 1) The meta-information classes (which store info like constructor names and arities) use base types like Char and Bool, which are also defined somewhere in ghc-prim. However, those modules need to import GHC.Generics, because they too will have representations. Do we have to make these modules mutually recursive? 2) The new GHC.Generics is far bigger than the previous, defining many more names. In particular, very basic names like P and S are now "taken". Text.ParserCombinators.ReadP (in base) clashes with this. In base this is easy to fix. But Data.Binary.Get (in binary) also gets a name clash. In general, I assume that the representation types will only be visible if GHC.Base is imported, so this won't be a big problem for user-defined modules. But what to do about all the boot packages? Should we choose more inconspicuous names? Also, in general, should I email you only with questions like these, or always CC cvs-ghc? Thanks, Pedro 2010/10/11 Simon Peyton-Jones <[email protected]<mailto:[email protected]>> Great!. You should be able to darcs get http://darcs.haskell.org/ghc-generic-11Oct10/ghc Then cd into that new directory and ./darcs-all get should get the rest. This repo has a * Clone of ghc, ghc-prim, base * Symbolic links for all the others So you can freely push to the clones (which no one else except me will use), but don't push to the others (else you'll affect the master repos). You need to have an account on d.h.o, which Simon M can give you if you don't have one already. You'll have to send him your ssh public key. Simon From: José Pedro Magalhães [mailto:[email protected]<mailto:[email protected]>] Sent: 11 October 2010 11:51 To: Simon Peyton-Jones Subject: Generic deriving in GHC Hello Simon, I am back in the Netherlands and ready to start working on generic deriving in GHC. Which branch should I use? Thanks, Pedro
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
