On Wed, Jan 9, 2013 at 11:38 PM, Joachim Breitner <[email protected]> wrote: > 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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
