I always thought that story was a bit unfortunate -- mostly because I don't believe a good solution emerged. I also find it odd that they felt the need to continually _remove_ Eval annotations. Leaving an unused extraneous Eval annotation in place should be mostly harmless, An extra dictionary being passed around here or there shouldn't destroy performance too badly -- you only need to pass them in when you are polymorphic in the argument type, and how often is your code really polymorphic _in something you want to arbitrarily seq_ in a performance sensitive part of your TCP/IP stack?

Asking to seq a polymorphic argument these days is generally taken as a sign that you are sprinkling seq's around without understanding why. We have strategies now for a reason.

-Edward Kmett

On Fri, Nov 6, 2009 at 1:38 AM, Stefan Holdermans <stefan@cs.uu.nl> wrote:
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_______________________________________________