[haskell-cafe] Monad and kinds

Tim Chevalier catamorphism at gmail.com
Fri Sep 5 23:11:37 EDT 2008


On Fri, Sep 5, 2008 at 7:23 PM, Derek Elkins <derek.a.elkins at gmail.com> wrote:
>
> This attitude is wrong.  Many potentially significant performance
> problems can easily be spotted and solved during construction without
> affecting the readability of the code, problems that would be much
> harder to diagnose at the end running a profiler.  This is especially
> crucial for library code.  The users of the library may be the ones that
> find the easily resolved space leak your profiling didn't reveal and now
> they can't do anything about it until a new version is released e.g.
> Data.Map.insertWith. A performance problem that renders your code
> unusable is a bug and catching it early or not making it in the first
> place is much better than catching it late.
>

Library writers don't write applications that use their code as part
of the testing process?

> A (highly related) analogy would be telling Scheme programmers (or
> Haskell programmers for that matter) not to use to tail recursive code
> until a profiler tells them to and transforming to a tail recursive
> style is much more intrusive than adding a strictness annotation.
>

Tail recursion isn't always a win in Haskell. I'm not much in touch
with the Scheme world, so can't speak to that.

> Highly competent Haskell programmers add strictness annotations
> relatively systematically.  The details of mixing eager and lazy code is
> one of the significant contributions to the pragmatics of programming
> lazy functional languages have made.  At another extreme, things like
> Chris Okasaki's data structures rely on a specific balance of eagerness
> and laziness.
>
> Also, it is easier (as in not impossible) to turn a strict in the
> elements data structure into a lazy one than the other way around.
>
> Eager by default or lazy by default are both have (actually dual)
> pitfalls that are best solved by a laziness or strictness annotation
> respectively.  There is no need to walk into those pitfalls with your
> eyes wide open.

That may be, but are the holes that one falls into due to unexpected
laziness and the ones that one falls into due to unexpected strictness
equally numerous? Are they equally deep?

Cheers,
Tim

-- 
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
Just enough: Obama/Biden '08.


More information about the Haskell-Cafe mailing list