On Tue, Jun 19, 2007 at 03:11:44AM +0100, 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.
I'll modify the derive tool to take this into account. I've never seen any comments on the effect of using SYB with data structures containing invariants such as Map's. I guess SYB can break these invariants quite easily, so should be used with care in some places.
No, it can't be used on Map etc in any reasonable way. You can't break the invariants because you can't do much of anything: -- This instance preserves data abstraction at the cost of inefficiency. -- We omit reflection services for the sake of data abstraction. instance (Data k, Data a, Ord k) => Data (Map k a) where gfoldl f z map = z fromList `f` (toList map) toConstr _ = error "toConstr" gunfold _ _ = error "gunfold" dataTypeOf _ = mkNorepType "Data.Map.Map" dataCast2 f = gcast2 f Stefan