I have read in the History of Haskell, that originally 'seq' should be a method of a type class, that can be automatically derived by a 'deriving' clause. It was also mentioned that this clean solution was dropped because of particular experiences with developing a parser. However the arguments appeared to me, like these were problems of debugging. I think that hacks are ok for debugging, such as dynamically finding a Show method for a message for 'error', although no Show constraint was given in the type signature. But I think that hacks are not ok for regular programming. In the History of Haskell it is told that the hack of making 'seq' not a member of a type class leads to invalid fusion optimization. While it is not possible to get rid of 'seq' anymore, wouldn't it be feasible to define a new type class with a new 'seq' - maybe just a new module, from where I can import the new 'seq' instead of the one from Prelude? This would also allow us to handle cases like this one: When I have a datatype like data T = A | B | C and I use 'seq' for it a lot, and once I have to switch to data T = Cons Int S data S = A | B | C and I like that 'seq' on T is strict both on Cons and on the constructors of S, this would be possible using a custom instance Seq T. Actually in stream-fusion:Data.Stream I found such a class, called Unlifted. How about moving this into a separate package? class Unlifted a where -- | This expose function needs to be called in folds/loops that consume -- streams to expose the structure of the stream state to the simplifier -- In particular, to SpecConstr. -- expose :: a -> b -> b expose = seq -- | This makes GHC's optimiser happier; it sometimes produces really bad -- code for single-method dictionaries -- unlifted_dummy :: a unlifted_dummy = error "unlifted_dummy"