Actually, standalone deriving doesn't really solve the boilerplate boilerplate problem. My original complaint here is that I don't want to explicitly declare a deriving (Data,Typeable) for every type used somewhere inside a larger type I am using. In this particular case, I am using SYB to autogenerate/autoparse XML. The Atom/RSS datatype has a lot of elements in it. Having to do an explicit declaration of deriving (Data,Typeable) for each of them is just a tremendous beat-down no matter where I do it. A simple solution to the problem is just to have the compiler automatically derive Data and Typeable for all classes. Perhaps initially there is some compiler flag like -fSYB. Slightly more elegant would be to not automatically derive if the user has done so explicitly and to add syntax to the deriving clause like "deriving ... not (Data,Typeable)" to tell the compiler that these instances should be unavailable for this type. A substantially more general/elegant solution would be for the compiler to derive instances automatically for any classes whose methods I use and for which there has been no explicit contradictory declaration. But I assume that is harder and having Data and Typeable means you can use SYB and not worry so much about deriving instances anymore. Most elegant would be for the user to be able to add derivable classes via import declarations, but again simply having Data and Typeable is a 95% solution and the perfect should not be the enemy of the good. -Alex- Simon Peyton-Jones wrote:
| does that help to keep it on the radar?-) | claus
Indeed! But please modify the wiki. Email has a half life of about 1 day!
S _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe