seq as type class method
ekmett at gmail.com
Fri Nov 6 10:11:13 EST 2009
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.
On Fri, Nov 6, 2009 at 1:38 AM, Stefan Holdermans <stefan at cs.uu.nl> wrote:
> 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 ﬁx 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 ﬁnd 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 ﬁxing their space leaks was
> simply not feasible in the time available to complete the
> project—not because they were hard to ﬁnd, but because making
> the necessary corrections was simply too heavyweight. This
> experience provided ammunition for the eventual removal of class
> Eval in Haskell 98."
> Libraries mailing list
> Libraries at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries