seq as type class method

[Henning Thielemann]

  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"