darcs pull syb-utils

update version

claus.reinke@talk21.com — Mon, 22 Sep Dayl 20:03:22 GMT

adapt example to new Ghc Api

claus.reinke@talk21.com — Mon, 22 Sep Dayl 20:01:02 GMT

update README with instance split, syb; mention haddock issues

claus.reinke@talk21.com — Tue, 9 Sep Dayl 11:42:12 GMT

oops, actually add Partial.hs file

claus.reinke@talk21.com — Tue, 9 Sep Dayl 11:30:16 GMT

move from 2- to 3-part split of instances: Standard, Partial, Dubious

claus.reinke@talk21.com — Tue, 9 Sep Dayl 11:12:22 GMT

As discussed on the libraries list, some instances that were 
preliminarily classified as Dubious are really just partial
(eg, the pointer type parameter is a phantom type, so there 
are no substructures of that type to traverse), and so are 
some previously classified as Standard (notably arrays).

So, now we have three instance modules:

Data.Generics.Instances.Standard: completely implemented
Data.Generics.Instances.Partial:  partially implemented
Data.Generics.Instances.Dubious:  don't quite fit Data

Partially implemented instances are usually for abstract
types, were reflection and gunfold are missing. Dubious
instances are things like (IO a) and (b -> a), where the
current instances do not traverse existing substructures
of type a (unlike fmap) (while it is possible to modify
these instances to support such traversals for transformations,
the type of queries prevents similar modifications due
to the contra-variant context in which the substructures
are embedded (IO, "realworld", function, ..).

One outlier is 'Ratio a', currently classified Standard:
it is partially implemented abstractly, partially implemented
concretely (with exposed constructor). This needs to be
rectified.

merge GHC.Syb.Instances0 into GHC.Syb.Instances (GHC #2438 was fixed)

claus.reinke@talk21.com — Tue, 9 Sep Dayl 10:47:11 GMT

follow syb split from base 4

claus.reinke@talk21.com — Tue, 9 Sep Dayl 10:45:51 GMT

update package version

claus.reinke@talk21.com — Tue, 19 Aug Dayl 13:42:21 GMT

explain change of plan for nested types

claus.reinke@talk21.com — Tue, 19 Aug Dayl 13:37:07 GMT

bail out of potentially infinite substructure type maps (nested types)

claus.reinke@talk21.com — Tue, 19 Aug Dayl 13:27:43 GMT

keep auto-generated changes.xml out of sdist (we don't want it in darcs)

claus.reinke@talk21.com — Sun, 10 Aug Dayl 12:43:06 GMT

add README

claus.reinke@talk21.com — Sun, 10 Aug Dayl 11:17:18 GMT

add example showData output to haddocks

claus.reinke@talk21.com — Sun, 10 Aug Dayl 10:41:41 GMT

document Data instances for abstract Ghc Api types

claus.reinke@talk21.com — Sun, 10 Aug Dayl 10:40:33 GMT

initial stab at haddocks

claus.reinke@talk21.com — Sun, 10 Aug Dayl 01:51:42 GMT

	haddock fights back:
	- I need to configure this package with the latest head,
	  for the standalone deriving fixes
	- there is no haddock 2 that builds with the latest head,
	  and no other version of haddock 2 will do (showing that
	  the Ghc Api client interface file incompatibility issue
	  can *not* always be worked around by rebuilding!)
	- no version of haddock seems to understand standalone
	  deriving, and I don't feel like repeating all instances,
	  so I've commented them out for haddock..

initial repo

claus.reinke@talk21.com — Sat, 9 Aug Dayl 20:11:47 GMT

    This syb-utils package contains some experimental modifications 
    of the Scrap Your Boilerplate libraries in base. In particular, 
    we make it possible 

    - not to import dubious Data instances by default (at the moment,
      those instances are inadvertedly reexported by other unrelated
      modules using Data.Generics, though, so we'd really need to 
      change that to get the full benefit)

    - to play with variants of everything/everywhere that avoid
      traversals of irrelevant substructures, using variants of
      generic query/transformation extensions that record their
      active domain

    - to get default definitions for Control.Monad.Functor fmap
      and Data.Traversable traverse from Data/Typeable

    The main purpose of this package is to support the discussion
    of these issues on generics and libraries at haskell.org

    - optionally, we also provide some Data/Typeable instances 
      for the Ghc Api types (via standalone deriving)