The base library and GHC 6.10

[Neil Mitchell]

Hi

> 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.

My opinion is that Data should remain in base. Data is much lower than
other classes, and provides reflection and examination of Haskell
values at runtime. You can layer uniplate and binary on top of Data,
and the Derive tool's next release will layer an additional 20 classes
on top of Data. In some ways Data is more primitive, and more
powerful, than other classes. The rest of SYB is a traversal
mechansim, which is much more of a library concern, so deserves to be
split off.

> 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.

Keeping dependencies short is good, and it will be hard to persuade
most library authors (including me) otherwise.

> Splitting off the above 5 packages would leave 106 modules and 16621 LoC
> in base. About 5% of the LoC, and 12.5% of the modules, would be in the
> new packages.

The goal of exposing a consistent base seems a sensible one, so all
those changes look good.

Thanks

Neil