On Wed, Jan 9, 2013 at 11:38 PM, Joachim Breitner
Am Mittwoch, den 09.01.2013, 15:11 +0100 schrieb Erik Hesselink:
We finally solved the problems by completely moving to strict map operations, strict MVar/TVar operations, and strict data types.
do you mean strict by policy (i.e. before storing something in a [MT]Var, you ensure it is evaluated) or by construction (by `seq` or `deepseq`’ing everything before it is stored)? In the latter case: Seq or deeqseq? Again in the latter case: Do you worry about the performance of repeatedly deepseq’ing an already deepseq’ed and possibly large value?
Strict by construction: we `seq` when storing in a var. This is similar to the primed functions in some places, and the new Data.Map.Strict. So repeatedly deepseq'ing isn't a problem: deepseq in our case is only used for debugging.
You are not the first user of Haskell who ends up with that approach to lazy evaluation. I’m not sure what that means for Haskell, though.
Well, we still use the 'normal' lazy approach in most places. Only where we have persistent shared state do we use the above approach of making everything strict. This means updaters pay the computational price, not readers, which seems like a sane idea. Regards, Erik