<div dir="ltr"><div class="gmail_quote"><div>Hi Pedro,<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr">To be able to further develop SYB (see [1] for history), it's probably best to develop it as a separate package, which people can install, upgrade, etc. This would mean the library could be updated independently of GHC, and new GHC releases could then use the most recent version of the package.<br>
</div></blockquote><div><br>Agreed. We talked about this offline, but I wanted to chime in with a +1 here. Just as it would help the GHC developers for a third party to develop and maintain SYB, it would help the developers and users for SYB to be distributed and available as a separate package.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr">But how do these things merge? Can/should SYB be moved out of the base package? And, if this happens, can the library being developed as a separate package still use the automatic deriving mechanism?</div>
</blockquote><div><br>I think SYB should be extracted from 'base' into a package. It seems like the only technical thing that might prevent this extraction is the automatic deriving of Typeable and Data. Or does it prevent it? Can anyone clarify this?<br>
<br>As a side note, might this work have an impact on the Haskell Platform?<br><br>Thanks,<br>Sean<br></div></div></div>