Space leak question

[Will Ness]

Bertram Felgenhauer <bertram.felgenhauer <at> googlemail.com> writes:

> 
> Hi Will,
> 
> Will Ness wrote:
> > addition: with
> >   gaps k xs = minus [k,k+2..] xs
> > it also runs without the space leak, but with
> >   gaps k = minus [k,k+2..]
> > the leak reappears.
> 
> I'm not sure that I tried the same code as you did, but for me both
> these versions were leaky. I cannot explain why, but I see that in the
> resulting core (ghc ... -ddump-simpl) the [5,7..] list ends up as a top
> level constant, despite -fno-full-laziness. So the cause of the space
> leak remains the same -- the [5,7..] list is being shared among several
> invocations of g. Tricky.
> 
> Bertram
> 

Hi,

I've ended up with

 primes = 2 : g (fix g)
  where
   g xs = 3 : gaps 5 (unionAll [[x*x, x*x+2*x..] | x <- xs])

Here's the test entry:   https://ideone.com/qpnqe

The both "gaps" leak (25MB for 500k run) if "fix" is made internal function and 
there's no -fno-cse switch. 

But with the switch, one stops leaking, and the other goes to 120MB.

Tricky, one could say, is an understatement. :)

I wish (avoidable) space leaks could/would be considered a "bug" and compiler 
would find ways to avoid it, all by itself (or with a super-switch, "-fno-
leaks" say). 

Then we'd needn't worry about such things, and could just write such "mythical 
one-liners" with confidence. :)

Cheers, 

and thanks a lot,

  Will