Splitting SYB from the base package in GHC 6.10

[José Pedro Magalhães]

Hello all,

I'm initiating this discussion per suggestion of SP Jones and following from
[1]. 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.

Therefore, it was suggested that the entire Data.Generics.Basics module [2]
should remain in base. This module defines the Data class and several
associated functions and datatypes. I don't think anyone objected to this so
far: please correct me if I'm wrong, or object now.

Then it was also suggested that Data.Generics.Instances [3] could stay in
base (perhaps inside Basics as well). This, however, would prevent dealing
with the "dubious" Data instances [4], and this was one of the motivating
factors to split SYB from base. This refers concretely to the instances:

instance (Data a, Data b) => Data (a -> b)
instance Typeable a => Data (IO a)
instance Typeable a => Data (Ptr a)
instance Typeable a => Data (StablePtr a)
instance Typeable a => Data (IORef a)
instance Typeable a => Data (ForeignPtr a)
instance (Typeable s, Typeable a) => Data (ST s a)
instance Typeable a => Data (TVar a)
instance Typeable a => Data (MVar a)
instance Typeable a => Data (STM a)
instance (Data a, Integral a) => Data (Ratio a)


These instances are defined in such a way that they do not traverse the
datatype. In fact, there is no other possible implementation, and this
implementation at least allows for datatypes which contain both "regular"
and "dubious" elements to still have their "regular" elements traversed.
However, this implies that a user cannot redefine such instances even in the
case where s/he knows extra information about these types that would allow
for a more useful instance definition, for instance.

Claus, please correct me if I'm wrong, but if the 11 "dubious" instances (or
perhaps less, given your message in [5]) go in the syb package and the
remaining, "standard" ones stay in base, we:
- Mantain backwards compatibility regarding SYB in 6.10, and
- Can still deal with the issue by releasing a new version of the syb
package later, independently of GHC.
Since the deadline for 6.10 is approaching I'm assuming that we should try
to minimize the changes there, while keeping future development in the syb
package as open as possible.


Finally, there are module naming issues, which are probably secondary to the
issue above and can be dealt with separately and later.


Thanks,
Pedro

[1] The base library and GHC 6.10:
http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9929
[2]
http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Data-Generics-Basics.html
[3]
http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Data-Generics-Instances.html
[4] http://www.haskell.org/pipermail/generics/2008-June/000347.html
[5] http://article.gmane.org/gmane.comp.lang.haskell.libraries/9957
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20080901/4de68177/attachment.htm