The base library and GHC 6.10

[Simon Peyton-Jones]

Let's think of what we are trying to achieve.

Plan A:

·         The class Data is defined in 'base'

·         The SYB library builds on it

·         Other libraries may build on it, independent of SYB

Plan B:

·         The class Data is defined in SYB

·         Other libraries that want reflection-like facilities must build on SYB

I think we were proposing to carry out Plan A.  If so, then it would make sense for instances of Int, Maybe, tuples, etc to be in 'base' too; otherwise you have to import SYB anyway to get those instances.

Claus says that "half the instances of Data are controversial".  Is that really right Claus?  Isn't it just functions and IO?

My suggestion:

·         Plan A

·         Simple, obvious data instances (eg Bool, Maybe, lists) go in base

·         A handful of controversial instances go in SYB
This more or less what Ross suggested.

Jose, should we be copying the 'generics' list?

We need a chairperson for this discussion, to drive us to a timely conclusion.  Jose: would you be willing to play that role?

Simon

From: libraries-bounces at haskell.org [mailto:libraries-bounces at haskell.org] On Behalf Of José Pedro Magalhães
Sent: 01 September 2008 07:54
To: libraries at haskell.org; Claus Reinke
Subject: Re: The base library and GHC 6.10

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<mailto: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<mailto: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/e09eb91a/attachment.htm