<div dir="ltr">Hello,<br><br>Thanks for your answer. Replying below:<br><br><div class="gmail_quote">On Thu, Aug 21, 2008 at 11:16, Simon Peyton-Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</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;">
<div link="blue" vlink="purple" lang="EN-GB">
<div>
<div style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
<div><div>
<p style="margin-bottom: 12pt;">I understand that with the
proposed base package breakup [1], SYB will be moved to a separate package. But
I still don't know how this will reflect on the development of the library. In
particular:<br>
<br>
1) Where is the source code going to be hosted? Here in Utrecht we currently
have a repository with several (cabalized) generic programming libraries, SYB
included. But maybe SYB will stay in the same repository as GHC?<span style="color: rgb(31, 73, 125);"></span></p>
</div><p style="margin-bottom: 12pt;"><span style="font-size: 11pt; color: rgb(31, 73, 125);">I don't think it
matters too much where it's hosted. For us it might be convenient if it
was on <a href="http://darcs.haskell.org" target="_blank">darcs.haskell.org</a> because it reduces the number of ways in which you can
get stuck. But servers are fairly reliable so this probably isn't very
important.</span></p></div></div></div></div></blockquote><div><br>We might prefer to keep it in an SVN repository where we have other generic libraries, if that is not a big problem. If it is, it can always go to <a href="http://darcs.haskell.org" target="_blank">darcs.haskell.org</a> anyway.<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 link="blue" vlink="purple" lang="EN-GB"><div><div style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
<div><p style="margin-bottom: 12pt;"><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p><div>
<p style="margin-bottom: 12pt;"><br>
2) Can development proceed independently of GHC, i.e. can a new version of SYB
be released without a new version of GHC?<span style="color: rgb(31, 73, 125);"></span></p>
</div><p style="margin-bottom: 12pt;"><span style="font-size: 11pt; color: rgb(31, 73, 125);">Yes, I think that independent
development is part of the goal. The easiest way to achieve this is for SYB *<b>not</b>*
to be a GHC "core package". That is, not needed to build GHC (or
GHCi, or the GHC library). Then it's "just a library" like
GtK or LibCurl, and you can upgrade it whenever you like.</span></p>
<p style="margin-bottom: 12pt;"><span style="font-size: 11pt; color: rgb(31, 73, 125);">It's more complicated
if it's a core package. For example, if the GHC API uses SYB to implement
something, then package "ghc-6.9" will depend on package "SYB-2.7",
and while you can also have SYB-3.2 installed the ghc-6.9 package will still
use the "SYB-2.7".</span></p></div></div></div></div></blockquote><div><br>I think indeed having it outside of the core is the best thing.<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 link="blue" vlink="purple" lang="EN-GB"><div><div style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
<div><p style="margin-bottom: 12pt;"><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p><div>
<p style="margin-bottom: 12pt;"><br>
3) How does the separation affect the automatic instance deriving mechanism?<br>
<br>
<span style="color: rgb(31, 73, 125);"></span></p>
</div><p style="margin-bottom: 12pt;"><span style="font-size: 11pt; color: rgb(31, 73, 125);">It think it'd make
sense for the classes Data and Typable themselves to remain in a "core
package", precisely because the deriving mechanism generates code for
them. If you change the method signatures, the code has to change, for
example. But all the library code layered on top can be in the SYB package.</span></p></div></div></div></div></blockquote><div><br>Ok, that makes sense. Only any changes to methods in Data would need to wait for a new version of GHC. But those should be kept to a minimum, if any at all. It's just a pity that so many methods are inside the Data class (like gmapQ and friends). But then again, there is a reason for them to be there, and it's probably not a good idea to change those anyway. Most development should proceed by adding new things on top of the existing Data class core.<br>
<br>What about instances of Data for the base types? Here I see a few possibilities:<br>1) No types have instances in core. Those could be in the SYB package, or the user could use stand-alone deriving to get them (if that is possible).<br>
2) All types have instances in core, similar to the current Data.Generics.Instances situation. This implies that the situation discussed in [1] (inconvenient Data instances) will remain.<br>
3) Something between the previous two, such as the 'standard' Data instances staying in core, and the others going to the SYB package (where they could be thought over, or separated into another module which is not imported by default).<br>
<br><br>Pedro<br><br>[1] <a href="http://www.haskell.org/pipermail/generics/2008-June/000347.html" target="_blank">http://www.haskell.org/pipermail/generics/2008-June/000347.html</a><br></div></div></div>