seq as type class method

[Edward Kmett]

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 at 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_______________________________________________
>
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20091106/a2ca5640/attachment-0001.html