...

Does anyone out there *want* functions and IO in Data?

I have a feeling you sometimes need those instances to make the typechecker happy, even though you aren't actually doing anything generic on those parts of the types.

syb-with-class has also defined IO and (->) instances, but no comment as to why.

I found this remark in "Scrap More Boilerplate: .." (section 5.3, non-representable data types): Lastly, it is convenient to give Data instances even for types that are not strictly data types, such as function types or monadic IO types. Otherwise deriving ( Data ) would fail for a data type that had even one constructor with a functional argument type, so the user would instead have to write the Data instance by hand. Instead, we make all such types into vacuous instances of Data. Traversal will safely cease for values of such types. However, values of these types can not be read and shown. So the convenience hypothesis seems correct. The problem with this is that it assumes that the vacuous instances do not involve any types that the generic traversals are operating on. Also, while I could add such a vacuous instance Data (a->b), and then use deriving Data over the remaining types, I cannot remove an existing instance Data (a->b), nor can I easily override its effects. I suggest to separate the vacuous from the proper instances, and to expose only the former via Data.Generics. That way, the convenience is only an import away, but doesn't get in the way of non-standard applications. Claus