containers: to be or not to be (strict, in this case)?

[Isaac Dupree]

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