On Thu, Aug 28, 2008 at 13:12, Ian Lynagh
<igloo@earth.li> wrote:
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