Control.Eff.Loop

In rare occasions GHC optimizes innocent looking loops into space-leaking monsters. See the discussion here: GHC issue 13080 for more details, or this blog post about space leaks in nested loops

These functions in this module might help, at least in conjunction with the -fno-full-laziness GHC option.

There is a unit test in the sources of this module, which can be used to do a comperative heap profiling of these function vs. their counterparts in the base package.

Here are the images of the profiling results, the images show that the functions in this module do not leak space, compared to the original functions (forever and replicateM_):

Since: extensible-effects-concurrent-0.4.0.0

Documentation

foreverCheap :: Monad m => m a -> m ()

A version of forever that hopefully tricks GHC into not creating a space leak. The intuition is, that we want to do something that is cheap, and hence should be recomputed instead of shared.

Since: extensible-effects-concurrent-0.4.0.0

replicateCheapM_ :: Monad m => Int -> m a -> m ()

A version of replicateM_ that hopefully tricks GHC into not creating a space leak. The intuition is, that we want to do something that is cheap, and hence should be recomputed instead of shared.

Since: extensible-effects-concurrent-0.4.0.0