Hello,
On Thu, Aug 28, 2008 at 13:12, Ian Lynagh
First the easy bit: The Data.Generics hierarchy is going to have a separate maintainer, and I think that everyone is agreed that it should be pulled out into an "syb package". I'll treat this as not part of base from here on.
The only thing still being debated here is whether the Data class itself should remain in base or not. Some people believe that it should remain in base, as it is desirable to have Data instances for as many types as possible, and because there is a resistance among library writers against adding dependencies. The counter argument is that there are many other classes that the same is true of (e.g. uniplate, syb-with-class, binary), and it does not scale to put all of these classes into base. Also, by requiring a dep to be added even for the classes that have historically been included in base, adding dependencies for the sake of providing instances may become more socially acceptable.
Is there a way not to have the Data class in base while still preserving the deriving mechanism? I think that one big reason for the popularity of SYB is not only the fact that it comes with GHC but also that you get support for generics on user-defined datatypes for "free". So if there is no way to have derivable Data with Data outside base, then I think Data should stay in base. Pedro