4 ms·

here is a method that can help debug space leaks: http://neilmitchell.blogspot.com/2015/09/detecting-space-leaks.html http://neilmitchell.blogspot.com/2015/09/d

• zzalpha 10y ago
  I wish the problem was simply detecting and isolating space leaks. My experience is that actually fixing them can be incredibly difficult, hence my comment about needing to understand the gory details about how the runtime evaluates lazy expressions. Heck, that post even uses the phrase "Attempt to fix the space leak" as it's often not an obvious slam dunk. Sometimes it even devolves to peppering !'s around until the problem goes away.
  • dllthomas 10y ago
    > My experience is that actually fixing them can be incredibly difficult My experience differs, FWIW. If you know where you're creating too many thunks, and you force them as you create them, they don't accumulate. Making sure you actually are forcing them, and not simply suspending a "force this", is probably the trickiest bit until you're used to the evaluation model.
    • zzalpha 10y ago
      If you know where you're creating too many thunks, and you force them as you create them, they don't accumulate. Translation: if you've internalized the way Haskell code is compiled and executes, so that you can easily reason about how lazy evaluation is actually implemented, you can solve these problems. If not, it devolves to throwing !'s in and praying. Which is basically my point. If I don't have a hope of solving common space leaks without deeply understanding how Haskell is evaluated, that's a real challenge for anyone trying to learn the language.
      • theoh 10y ago
        This sounds a bit FUD-ish. Programming in any language involves understanding the evaluation strategy. You seem to be advocating languages that can be used with a level of ignorance or innocence which in practice just isn't possible. https://en.wikipedia.org/wiki/Evaluation_strategy https://en.wikipedia.org/wiki/Evaluation_strategy
        • zzalpha 10y ago
          I disagree. I contend that most of the time folks ignore the evaluation strategy for eagerly evaluated languages because they're simply easier to reason about. That strikes me as objectively true on its face and I believe most Haskellers would concede that point. The only time I can think of where that's not the case is when microoptimizing for performance, where the exact instructions being produced and their impact on pipelining and cache behaviour matter. But that's in general far more rare than one encounters space leaks in idiomatic Haskell. Heck, one just needs to read about two of the most common Haskell functions to hit concerns about space leaks: foldl and foldr. It's just part of the way of life for a Haskeller. There's simply no analog that I can think of in the world of eagerly evaluated languages that a) requires as much in-depth knowledge of the language implementation, and b) is so commonly encountered. The closest thing I can come up with in a common, eager language might be space leaks in GC'd languages, but they're pretty rare unless you're doing something odd (e.g. keeping references to objects from a static variable).
          • platz 10y ago
            You're taking issue with material that is covered in every haskell 101 course worth it's salt (how to understand the properties of foldl and foldr). We typically don't evaluate the efficacy of a language contingent on someone who is missing fundamental, well-known concepts about the language. Also, I don't think folks "ignore the evaluation strategy for eagerly evaluated languages". They simply learn it early in in their programming experience.
            • zzalpha 10y ago