id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,os,architecture,failure,difficulty,testcase,blockedby,blocking,related
917,-O introduces space leak,claus.reinke@…,,"consider the following variant of a popular space problem
{{{
initlast :: (()->[a]) -> ([a], a)
initlast xs = (init (xs ()), last (xs ()))

main = print $ case initlast (\()->[0..1000000000]) of
                 (init, last) -> (length init, last)
}}}

the long list has been wrapped in abstractions to avoid
sharing, gaining constant space processing rather than
the space leak in the original code - see

http://www.haskell.org/pipermail/haskell-cafe/2006-September/018447.html

http://www.haskell.org/pipermail/haskell-cafe/2006-September/018464.html

this works nicely if compiled without -O, but unfortunately,
-O reintroduces the space leak (apparently lifting and sharing
the common and space-expensive subexpression).

1. I didn't see a ticket for this issue, so I wanted to record the example

2. avoiding sharing isn't always possible, so it would be nice if one could 
""bypass"" sharing in such cases. in the old g-machine, that might have 
been as simple as introducing a pragma that tells the compiler to omit
the update after the eval in the code for some subexpression (so the
original application node would not be overwritten by the space-expensive
result, trading time for space). is there a chance for a similar trick
in GHC? so one might write code like this (handwaving:-):
{{{
initlast :: [a] -> ([a], a)
initlast xs = (init ({-# COPY #-} xs), last ({-# COPY #-} xs))

main = print $ case initlast [0..1000000000] of
                 (init, last) -> (length init, last)
}}}",bug,new,lowest,_|_,Compiler,6.5,,,prokhorenkov@… pho@… mail@… ezyang@…,Unknown/Multiple,Unknown/Multiple,None/Unknown,Unknown,,,,