Today, I was playing with Stefan O'Rear's genericserialize package
when I noticed that Data.Map doesn't play well with Data.Generics.
Specifically, here is its instance for Data:
-- 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
The gfoldl and dataCast2 methods are okay, but I'm not sure about all
the others.
Now, I can understand why whoever wrote Data.Map doesn't want to
expose the internals, but couldn't we at least have a nice way to
deconstruct one and a nice way to build one,without having to write
hard-coded Map code? I particularly don't like the fact that toConstr
doesn't work on it.
Multiply this times four to account for the fact that Data.Set,
Data.IntMap, and Data.IntSet have the same problem.
I also noticed that Data.ByteString.Word8 has a rather silly instance
(it exposes the innards instead of doing something usefull), and that
Data.Array has the same problem as Data.Map -- presumably the other
IArray instances do too.
I think the best way might be to add a few constructors to the DataRep
and ConstrRep types, which I reproduce here:
data DataRep
= AlgRep [Constr] | IntRep | FloatRep | StringRep | NoRep
data ConstrRep
= AlgConstr ConIndex
| IntConstr Integer
| FloatConstr Double
| StringConstr String
(I must also marvel at how strangely named the StringRep/StringConstr
constructors are -- they seem to be used exclusively for the Char
type.)
Please discuss! Oh, and by the way, I'd like my nuclear power plant
painted red, thank you ;-).
