Different implementation for lines to fix a space leak (was:
Make lines stricter ...)
daniel.is.fischer at web.de
Mon Oct 4 15:44:31 EDT 2010
On Monday 04 October 2010 20:15:07, Duncan Coutts wrote:
> On 24 September 2010 15:21, Daniel Fischer <daniel.is.fischer at web.de>
> > Proposal: A stricter implementation of lines.
> > Reason: The current implementation causes a space leak (cf.
> > http://homepages.inf.ed.ac.uk/wadler/papers/leak/leak.ps), at least in
> > GHC.
> > The proposed implementation fixes the leak at the small cost of being
> > stricter if the first _|_ in the String is the first character of a
> > line.
> > Discussion period: Three weeks, until 15th October (because of ICFP).
> > Ticket: http://hackage.haskell.org/trac/ghc/ticket/4334
> My gut instinct is that we should not make lines stricter.
I didn't see a way without changing the strictness properties at first.
Now there *seems* to be one, although I have doubts concerning its
reliability to fix the leak. It's certainly more delicate than the stricter
> Generally the list library is as lazy as possible, except when there are
> compelling reasons otherwise. I am not yet convinced that this
> proposal meets that standard.
> Have we thought about the opposite issue, that there may be programs
> that rely on the current non-strict version for correctness or memory
The possibility that some programmes rely on the current behaviour
Though, the only change in behaviour is when the first Char on a line is
bottom, so I don't expect it would affect many programmes.
The memory behaviour can only be worse (by more than a few bytes) when the
first Char on a line is the result of a space-demanding computation for the
stricter version and not at all (as far as I can see) for the new
I'd be surprised if that affected any programme negatively.
> We currently have an open proposal on making intersperse
> less strict because it caused practical problems (unexpected memory
> There's also an issue of consistency with other functions in the list
> library. The lines function is similar in many ways to group /
> groupBy, and with the proposed change the strictness properties of
> these functions would be inconsistent. Such inconsistency has a cost
> in terms of programmers being able to predict and reason about
> strictness and space use (simply because if its inconsistent then it
> is harder to remember).
Agreed. That's why I favour the new suggestion (until someone comes forth
with a reliable way to fix the leak or someone finds that it doesn't fix
the leak in real use cases - it worked in my tests, but those were fairly
> The strictness of lines is pretty subtle. I think it would help our
> discussion if people reading this thread look at the strictness
> properties given in the ticket.
More information about the Libraries