Generic deriving in GHC

[Simon Peyton-Jones]

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:jpm at cs.uu.nl]
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 <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
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:jpm at cs.uu.nl<mailto:jpm at cs.uu.nl>]
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cvs-ghc/attachments/20101015/02eaea08/attachment-0001.html