seq as type class method

[Stefan Holdermans]

Henning,

>> If I understood it correctly, the problem was more general than  
>> just debugging. Every introduction of seq in a function could  
>> result in the requirement to also adapt the type signatures of  
>> calling functions.

> Sure, but why was this a problem? Because they had to re-arrange a  
> lot, and had to change the signature each time. But once that re- 
> arrangement settles, it would be nice to have the Seq type  
> constraint, right?

I cannot tell whether *I* would find it problematic in practice. Hudak  
et al. write:

   "However, the limitations of this solution soon became apparent.
   Inspired by the Fox project at CMU, two of Hughes’s students
   implemented a TCP/IP stack in Haskell, making heavy use of
   polymorphism in the different layers. Their code turned out to
   contain serious space leaks, which they attempted to fix using
   seq. But whenever they inserted a call of seq on a type
   variable, the type signature of the enclosing function changed
   to require an Eval instance for that variable—just as the
   designers of Haskell 1.3 intended. But often, the type
   signatures of very many functions changed as a consequence of a
   single seq. This would not have mattered if the type signatures
   were inferred by the compiler—but the students had written them
   explicitly in their code. Moreover, they had done so not from
   choice, but because Haskell’s monomorphism restriction required
   type signatures on these particular definitions [...]. As a
   result, each insertion of a seq became a nightmare, requiring
   repeated compilations to find affected type signatures and
   manual correction of each one. Since space debugging is to some
   extent a question of trial and error, the students needed to
   insert and remove calls of seq time and time again. In the end
   they were forced to conclude that fixing their space leaks was
   simply not feasible in the time available to complete the
   project—not because they were hard to find, but because making
   the necessary corrections was simply too heavyweight. This
   experience provided ammunition for the eventual removal of class
   Eval in Haskell 98."

Cheers,

   Stefan