Haskell Lazy Evaluation
Discussions center on the pros and cons of Haskell's default lazy evaluation, including performance issues like space leaks and thunks, comparisons to strict languages, and whether it should be optional or fixed.
Activity Over Time
Top Contributors
Keywords
Sample Comments
Can you elaborate on why Haskell's laziness is a dealbreaker?
Unless you have a space leak, how is laziness a weakness there?
What about the performance challenges caused by lazy evaluation?
You can in a lazy language, like Haskell.
Haskell would due to lazy evaluation.
I don't use Haskell but didn't I read recently that the latest version of Haskell addresses this common concern by allowing you to turn off laziness altogether so everything evaluates eagerly?
Can you give me an example of a domain where laziness is not desirable? I only do Haskell for side projects, so perhaps I lack exposure to some domains.
Is Haskell's default lazy evaluation really a flaw that needs to be fixed? I personally like it, I find that most of the time lazy evaluation is what I need instead of strict.
Haskell is lazy by default, and sometimes builds up large unevaluated expression trees that need to be forced. Other languages are eager, but litter the code with abstractions like Callables and Futures and channels just to not do something.
Isn't Haskell somewhat like that, due to being lazy by default?