Bas van Dijk
Also in my experience (with generics support in aeson and cereal) it's a very good idea (performance-wise) to INLINE your methods like I did in my previous message. Of course the only way to know for sure is the create some (criterion) benchmarks.
btw, how much is GHC able to optimize the GHC.Generics based NFData instance as e.g. compared to what GHC is able to optimize with deepseq-th[1]?
One last issue: Say I have a type like: "data T = C !Int" Currently GHC Generics can't express the strictness annotation. This means that your deepseq will unnecessarily evaluate the Int (since it will always be evaluated already). It would be nice if the strictness information could be added to the K1 type. (José, would it be hard to add this to GHC.Generics?)
that's btw one thing that I tried hard to avoid in deepseq-th[1], by having a hacky predicate decWhnfIsNf :: Dec -> Q (Maybe Bool) whis is able to detect whether WHNF is the same as NF for a given declaration; e.g. in the following case (see also the example in [1]): data Foo = Foo !Int !Int !Int data Bar = Bar !Foo !Foo the instance generated would be: instance NFData Foo instance NFData Bar since the WHNF=NF property holds for Foo as well as for Bar [1]: http://hackage.haskell.org/packages/archive/deepseq-th/0.1.0.2/doc/html/Cont...