Hello,

On Wed, Sep 3, 2008 at 13:57, Ross Paterson <ross@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@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