Ian Lynagh wrote:
If so, the first "pro" isn't a pro at all. Debatably it's a con - it would make it less convenient to derive instance Data for types containing IO etc.
maybe in those cases of "convenience" we could use a tool like Data.Derive, and make some name to derive with it like "DubiousData". Then the dubious Data instances wouldn't have to be defined/imported. I wonder if it would be possible to have Derive have a "NotSoDubiousData" that somehow figured out whether dubious types were involved and rejected them.. (Admittedly, last I tried, using Derive or DrIFT for a project that wasn't using it already, was much harder than the built-in deriving mechanism) here's an example (which don't know enough to say whether it supports any particular position) : say we have a type data Something a = Something a (IO a) If we want instance (Data a) => Data (Something a) ignoring the IO member but traversing the "a" member, then if we use the normal deriving where we have dubious instances, then (Something (a->b)) is going to be in Data even if it shouldn't be, and it will be easy not to notice. Given how popular polymorphism is in Haskell, I guess this is fairly likely to happen? -Isaac