Splitting SYB from the base package in GHC 6.10

[José Pedro Magalhães]

Hello,

On Wed, Sep 3, 2008 at 13:57, Ross Paterson <ross at soi.city.ac.uk> wrote:

> Another attempt:
>
> These [standard] instances are uncontroversial and can accompany the
> Data class:
>
>    [] Maybe Either () tuples
>    Bool Ordering Char Double Float Integer
>     Int Int8 Int16 Int32 Int64 Word Word8 Word16 Word32 Word64
>
> These instances could also be [standard], after fixing:
>
>    Ratio Complex


So Ratio would have to be given a proper gfoldl definition, to fits its
unfold:

gunfold k z c | constrIndex c == 1 = k (k (z (:%)))


Complex has a derived instance. In Data.Complex:

data (RealFloat a) => Complex a
  = !a :+ !a
# if __GLASGOW_HASKELL__
        deriving (Eq, Show, Read, Data)
# else
        deriving (Eq, Show, Read)
# endif

Was there a problem with this?


Regarding the other places that have to be changed [1]:

./array/Data/Array.hs

The Data instance of Array should be moved from Data.Generics.Instances into
Array, to avoid syb dependency.

./containers/Data/IntMap.hs
./containers/Data/IntSet.hs
./containers/Data/Map.hs
./containers/Data/Sequence.hs
./containers/Data/Set.hs
./containers/Data/Tree.hs
./network/Network/URI.hs
./packedstring/Data/PackedString.hs

As far as I can see, these are not problematic, but the imports should be
fixed to avoid bringing into scope all the instances.

./haskell-src/Language/Haskell/Syntax.hs
./template-haskell/Language/Haskell/TH/Quote.hs
./template-haskell/Language/Haskell/TH/Syntax.hs

The use of Ratio instances here is not problematic if the instance for Ratio
is fixed?

./bytestring/Data/ByteString/Internal.hs
./bytestring/Data/ByteString/Lazy/Internal.hs

These depend on an instance for ForeignPtr Word8. What to do here?
Reclassify instances for types with phantom types into "standard", since
there is nothing to traverse?


On Wed, Sep 3, 2008 at 13:23, Claus Reinke <claus.reinke at talk21.com> wrote:

> (*) of course, it would be nice if ghc's deriving mechanism was
> based on a derived instance specification in the module providing
> the class, rather than being hardcoded into the compiler itself;
> so even with 'Data' out of 'base', that part currently cannot be
> changed without updating ghc. or if class aliases allowed the
> generated old-style 'Data' instances to be re-interpreted as
> 'DataA' and 'DataB' instances.. but none of that is realistic for
> the current split decision.


I fully agree that the deriving mechanism should be customizable. That would
make generic programming in general much nicer in Haskell. However, I don't
think it's realistic to expect such changes for 6.10...


Thanks,
Pedro

[1] 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/20080904/887ac99d/attachment-0001.htm