<div dir="ltr">Hello,<br><br><div class="gmail_quote">On Thu, Aug 28, 2008 at 13:12, Ian Lynagh <span dir="ltr"><<a href="mailto:igloo@earth.li" target="_blank">igloo@earth.li</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
First the easy bit: The Data.Generics hierarchy is going to have a<br>
separate maintainer, and I think that everyone is agreed that it should<br>
be pulled out into an "syb package". I'll treat this as not part of base<br>
from here on.<br>
<br>
The only thing still being debated here is whether the Data class itself<br>
should remain in base or not. Some people believe that it should remain<br>
in base, as it is desirable to have Data instances for as many types as<br>
possible, and because there is a resistance among library writers<br>
against adding dependencies. The counter argument is that there are many<br>
other classes that the same is true of (e.g. uniplate, syb-with-class,<br>
binary), and it does not scale to put all of these classes into base.<br>
Also, by requiring a dep to be added even for the classes that have<br>
historically been included in base, adding dependencies for the sake of<br>
providing instances may become more socially acceptable.</blockquote><div> <br>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.<br>
<br><br>Pedro<br></div></div></div>