<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The issue is: SYB is being moved out of base into its own package.<br>
However, the Data class is, in a way, tied to base since it depends on the<br>
deriving mechanism.<br>
</blockquote>
<br></div>
My understanding is that the deriving mechanism would still work if class 'Data' was moved into 'syb', but changes in 'Data' would still need to be matched in the deriving mechanism (which isn't auto-generated from 'base', either). As long as 'syb' remains a core library, we can thus focus on assigning modules to 'syb' or 'base' by functionality.<div class="Ih2E3d">
</div></blockquote><br>So, here's a (possible) summary from a general perspective.<br><br>(1) Some people want to keep some parts of the SYB functionality in 'base', because these parts are closely linked to some parts of GHC. This is desired for convenience (and perhaps test coverage?).<br>
(2) Some people want to remove some parts of the SYB functionality from 'base', because they want to be able to maintain and release SYB separately.<br>(3) Some people in group #2 are not sure what should be left in 'base' or extracted into 'syb.'<br>
<br>My observations:<br>(A) I don't see 'syb' ever becoming something other than a core library for GHC, considering it's close family ties.<br>(B) I expect 'syb' to get updated and released more often than GHC. This is especially true considering the newfound interest.<br>
(C) I expect the 'syb' library will be tested using the current (and possibly past?) release(s) of GHC, because that's what releases will use in general. If something in a development version of GHC breaks SYB, then there may need to be a new 'syb' release for when that version of GHC is released. At that point, there may be a need for a temporary fork if other work is ongoing.<br>
(C) From a user's perspective I don't understand the splitting of SYB. Why is it that I can derive Data.Generics.Data, but I cannot actually use other functions built for it?<br><br>So, given all of the above (assuming it's correct), it seems to me that the benefit leans towards migrating everything SYB-related into the 'syb' library. Is the motivation/argument for group #1 very strong?<br>
<br>Hope this helps,<br>Sean<br></div></div>