The base library and GHC 6.10

[José Pedro Magalhães]

Hello,

This issue has been discussed before [1] and I got the impression all
instances were going to be in the syb package and not in base. I think it's
preferable to deal with the dubious instances issue [2] once SYB has been
put into its own package, but maybe the "standard" instances could stay in
base.

Regarding the naming issue: I would very much be in favor of entirely
renaming SYB to Generics.SYB altogether. I think the current name doesn't
make much sense (why Data? it doesn't really define a datastructure), and
simply calling it Generics is too broad, given that this is only one of the
libraries for generic programming around. This would also fit nicely with
other (upcoming) libraries for generic programming.


Thanks,
Pedro

[1] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9738
[2] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9672


On Mon, Sep 1, 2008 at 00:02, Claus Reinke <claus.reinke at talk21.com> wrote:

> Leaving Data.Generics.Basics in base while moving
> Data.Generics.Instances to syb raises the interesting issue of
> dealing with the accidental re-exports of Data.Generics.Instances
> from various places. Here is that list again (*):
>
>    $ find . -name '*hs' | grep -v _darcs | xargs grep -l 'Data.Generics' |
> grep -v Generics
>    ./array/Data/Array.hs
>    ./base/Data/Typeable.hs
>    ./bytestring/Data/ByteString/Internal.hs
>    ./bytestring/Data/ByteString/Lazy/Internal.hs
>    ./bytestring/Data/ByteString/Unsafe.hs
>    ./containers/Data/IntMap.hs
>    ./containers/Data/IntSet.hs
>    ./containers/Data/Map.hs
>    ./containers/Data/Sequence.hs
>    ./containers/Data/Set.hs
>    ./containers/Data/Tree.hs
>    ./haskell-src/Language/Haskell/Syntax.hs
>    ./network/Network/URI.hs
>    ./packedstring/Data/PackedString.hs
>    ./template-haskell/Language/Haskell/TH/Quote.hs
>    ./template-haskell/Language/Haskell/TH/Syntax.hs
>
> And here is a brief scan of what each of these is doing. References
> to 'standard' vs 'dubious' Data instances are wrt the suggested split
> in [1], with some possible refinements:
>
> - array: the Data instance for Array could be moved into array,
>    avoiding the need for instance imports and syb dependency?
>
> - bytestring: uses deriving, which for Internal.hs depends on
>    Data instances for Int [standard] and (ForeignPtr Word8)
>    [dubious]; would need to depend on syb; and import both
>    standard and dubious instances :-(
>
>    perhaps Data instances for type constructors with phantom
>    types should be re-classified into Standard, given that there
>    are no data objects to be traversed?
>
> - containers: IntMap.hs, IntSet.hs, Map.hs, Sequencs.hs, Set.hs,
>    Tree.hs define their own Data instances, or derive them in such
>    a way that they do not need to import any instances :-)
>
> - haskell-src: uses deriving, will need to depend on syb; depends
>    almost exclusively on standard instances (the only exception I
>    can see in a quick scan is Rational);
>
>    perhaps this is an argument in favour of moving the Data instance
>    for 'Ratio a' from Dubious to Standard: the parameter type is
>    never meant to be traversed, and tainting every client of 'Ratio a'
>    with the really bad instances is not a good idea. Opinions?
>
> - network: uses deriving, will need to depend on syb; depends
>    only on standard instances
>
> - packedstring: defines its own instances, no need to import any
>
> - template-haskell: uses deriving, roughly the same situation as
>    for haskell-src?
>
> Claus
>
> [1] see the last page of
>    http://www.haskell.org/pipermail/libraries/2008-July/010313.html
> [2] http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/#syb-utils<http://www.cs.kent.ac.uk/%7Ecr3/toolbox/haskell/#syb-utils>
>
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20080901/1adbdf16/attachment.htm