seq as a class method

[John Hughes]

>it seems that there is not yet a ticket about putting seq into a type class 
>(again).
>
>In my opinion, having seq available for every type is a serious flaw.  One 
>problem is that the law f = \x -> f x doesn't hold anymore since the equation 
>is false for f = _|_.  There was also a discussion on one of the mailing 
>lists some time ago which revealed that the Monad instance for IO doesn't 
>satisfy the monad laws because of the availability of seq for IO, I think.
>
>In addition, the automatic definition of seq for every type can make 
>implementation details visible which were thought of as completely hidden.  
>For example, it might make a difference whether one uses data or newtype for 
>a one-alternative-one-field datatype, even if the data constructor is hidden.
>
>I therefore propose to declare a class like this:
>
>	class Seq a where
>		seq :: a -> b -> b
>  
>
Oh please, no.

This sounds like a good idea in principle, but it was a nightmare in 
practice.

First, the implementation details and the difference between _|_ and 
const _|_
make a difference to space behaviour, and one needs a way to control that.
Hiding the differences can make space leaks *impossible* to fix.

Secondly, the need to insert and remove Seq contexts from type 
signatures during
space debugging is a major overhead. In my practical experience such 
overheads made
some desirable refactorings impossible to carry out in the time 
available for the
project.

Thirdly, the laws one loses are "nearly true" anyway, and that's very often
enough. See "Fast and loose reasoning is morally correct", POPL 2006. We
don't need to give up anything to make reasoning *as though* such laws held
sound, in most cases.

John