> Fortunately, this is easily possible with Haskell. You need to enable the BangPatterns feature and use exclamations ! in front of patterns for variables where you want the evaluation to be performed eagerly.<p>Of course, this is simple - you just enable a language extension so that the language you are referring to Haskell is no longer really Haskell. I think Haskell is a fine language, but given the amount of various language extensions that are needed for it to be usable in production without friction, it seems it will forever be a research language - and there is nothing wrong with that.
I have tried and failed to comprehend Haskell for my own uses. Certainly most of the examples in this article are meaningless gibberish to my smooth, practical brain. So kudos to those who grok the underlying math and find it a useful language.<p>That said, I am a fan of lazy evaluation in the right circumstances, and often find myself implementing lazy data structures (particularly in my Ruby programs).<p>Ultimately, though, I’m confused by this article which seems to be all about removing laziness from Haskell in ways that seem entirely counter to what I take to be its purpose. If you have to bend over backwards and rewrite your code in awkward ways to get the language to behave the way you want, maybe the project itself isn’t right for the language? It’s one thing to hack around a couple of isolated space issues in a larger context, but if you are enabling language extensions across the board by default to prefer eager evaluation, why are you using Haskell at all?
Wait, the first suggested fix for "lazy evaluation consumes too much memory" is "make it eager"? I'm sure I'm missing some nuance here, but that seems backwards.
The phrase "space leak" seemed unusual and a bit of a "tortured phrase", since I'm more familiar with this concept as "memory bloat" or just inefficiency in general. Upon a little more searching it appears to be mainly Haskell jargon.
> For now, this has nothing to do with lazy evaluation. Such implementation will be slow in every language. It happens because add doesn’t use tail-call recursion.<p>This is why I'll never really trust Haskell to be usable in a serious context. Haskellers will talk your ear off about how such restricted abstractions enable the compiler to optimize it to hell and back, and perfectly idiomatic Haskell can be compiled to almost-perfect machine code, but in point of fact GHC basically never does, and you still have to care about things like tail calls and design APIs to do things like continuation passing.
> all mainstream languages have eager evaluation models<p>That is incorrect, e.g. Java Streams (Javas built in library for functional processing of data) are lazy, which can surprise beginners. You say it's just an std lib and not a lazy programming language? Ok, the much older (but just as lazy) C# linq is directly integrated in the C# language, making the C# language both eager and lazy by default, depending on which parts you use.