I understand that with the proposed base package breakup [1], SYB will be moved to a separate package. But I still don't know how this will reflect on the development of the library. In particular:

1) Where is the source code going to be hosted? Here in Utrecht we currently have a repository with several (cabalized) generic programming libraries, SYB included. But maybe SYB will stay in the same repository as GHC?

I don’t think it matters too much where it’s hosted.  For us it might be convenient if it was on darcs.haskell.org because it reduces the number of ways in which you can get stuck.  But servers are fairly reliable so this probably isn’t very important.

2) Can development proceed independently of GHC, i.e. can a new version of SYB be released without a new version of GHC?

Yes, I think that independent development is part of the goal.   The easiest way to achieve this is for SYB *not* to be a GHC “core package”. That is, not needed to build GHC (or GHCi, or the GHC library).   Then it’s “just a library” like GtK or LibCurl, and you can upgrade it whenever you like.

It’s more complicated if it’s a core package. For example, if the GHC API uses SYB to implement something, then package “ghc-6.9” will depend on package “SYB-2.7”, and while you can also have SYB-3.2 installed the ghc-6.9 package will still use the “SYB-2.7”.

3) How does the separation affect the automatic instance deriving mechanism?

It think it’d make sense for the classes Data and Typable themselves to remain in a “core package”, precisely because the deriving mechanism generates code for them.  If you change the method signatures, the code has to change, for example.  But all the library code layered on top can be in the SYB package.

I hope I have this right!

Simon