Databases
StackOverflow2013
Postsdbo
POWhy does nested forever leak memory?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWhy does nested forever leak memory?
    primarykey
    data
    text
    <p>This code leaks memory (very fast, be prepared to kill it soon if you try it):</p> <pre><code>import Control.Monad (forever) main = do forever $ forever $ return () </code></pre> <p>(Compiled with -O2, -O, -O0..., ghc 7.0.3) I don't understand why should this leak - I am using quite a lot of such code with exception handler between the forever's and I don't quite understand why is this supposed to leak memory..</p> <p>I just looked into source for Control.Monad and found this:</p> <pre><code>{- Note [Make forever INLINABLE] If you say x = forever a you'll get x = a &gt;&gt; a &gt;&gt; a &gt;&gt; a &gt;&gt; ... etc ... and that can make a massive space leak (see Trac #5205) In some monads, where (&gt;&gt;) is expensive, this might be the right thing, but not in the IO monad. We want to specialise 'forever' for the IO monad, so that eta expansion happens and there's no space leak. To achieve this we must make forever INLINABLE, so that it'll get specialised at call sites. Still delicate, though, because it depends on optimisation. But there really is a space/time tradeoff here, and only optimisation reveals the "right" answer. -} </code></pre> <p>This <a href="http://hackage.haskell.org/trac/ghc/ticket/5205" rel="noreferrer">bug</a> is supposedly 'fixed'; unfortunately it seems that the nested forever triggers the bug again. Interestingly enough, this definition of forever (borrowed from Control.Monad) triggers the bug:</p> <pre><code>forever a = a &gt;&gt; forever a </code></pre> <p>While the following definition works without problems:</p> <pre><code>forever a = a &gt;&gt;= \_ -&gt; forever a </code></pre> <p>There's something fishy in the <code>&gt;&gt;</code> operator, as I would this code to be equivalent.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USondra
    1. USondra
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POWhy does nested forever leak memory?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POWhy does nested forever leak memory?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POWhy does nested forever leak memory?
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload