Claus Reinke wrote:
The idea being to abstract over every application of the container constructors to the element type, then to supply either strict or non-strict application. Ultimately, one might prefer a type-constructor-based abstraction instead, to gain additional performance, but this should be at least as good as the current situation (perhaps with an INLINE on the parameterised versions), without the duplication.
the "Box" approach is attractive but performance-unoptimal... we can try that type-constructor stuff. Is it like: data IntMap_ strictness a = ... --(not including "strictness" values) data Strict data Lazy class Strictness s where ... well, it turns out to have similar performance issues to passing around ($) or ($!), except they'd be resolved in the compiler by SPECIALIZE rather than INLINE stuff (I guess). Anyway, the compiler basically can't optimize away Box at all. And changing the strictness of a Box-based IntMap, would be linear time rather than constant (zero) time for a purely newtype-based solution (if indeed they need to be separate types, rather than just different modules with different implementations of e.g. insertWith for the same data-type). -Isaac