[Hs-Generics] Re: Splitting SYB from the base package in GHC 6.10

[Sean Leather]

> The issue is: SYB is being moved out of base into its own package.
>> However, the Data class is, in a way, tied to base since it depends on the
>> deriving mechanism.
>>
>
> 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.
>

So, here's a (possible) summary from a general perspective.

(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?).
(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.
(3) Some people in group #2 are not sure what should be left in 'base' or
extracted into 'syb.'

My observations:
(A) I don't see 'syb' ever becoming something other than a core library for
GHC, considering it's close family ties.
(B) I expect 'syb' to get updated and released more often than GHC. This is
especially true considering the newfound interest.
(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.
(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?

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?

Hope this helps,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/generics/attachments/20080901/78632b33/attachment.htm