-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Neil Mitchell wrote:
Hi
Thinking about this slightly further...
For the implementation, Data.Derive has a special case for lists, tuples and Maybe. Its a shame that only a restricted number of types are supported - things like Data.Map/Data.Set can be supported perfectly, apart from restrictions in Template Haskell.
There are two cases.
1) The data structure contains values, in specific places. Lists, tuples, Either etc. are all like this. The rules in the paper cover all these situations.
2) The data structure contains values, but their place is a feature of the data structure - i.e. Map/Set. In this case the right thing to do is probably to do fromList/toList pairs on them.
Use Data.Traversable somehow - lots of things are instances of that. I'm just reading a paper about it... "A similar benefit can be found in the reassembly of a full data structure from separate shape and contents. This is a stateful operation, where the state consists of the contents to be inserted; but it is also a partial operation, because the number of elements provided may not agree with the number of positions in the shape." (p.10 http://web.comlab.ox.ac.uk/oucl/work/bruno.oliveira/iteratorJFP.pdf ) That reminded me of the 'uniplate' function... I haven't thought too closely about this, but it feels right. Also I wonder, since we can do deriving Functor, and Traversable instances are equally straightforward according to the paper, should we have deriving(Traversable)? Of course this would depend on the order of the constructor arguments just like deriving Ord, etc, do. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeUKDHgcxvIWYTTURApT5AKCB1QG4cgMoORIAf65LsyV1DFJc7wCgi2BJ wpKuYhtPZRriZ1qPzpy1Xe8= =a8ir -----END PGP SIGNATURE-----