Avoiding space leaks at all costs
kodimensional.dev
Avoiding space leaks at all costs
1–10 of 47 posts
Re: Avoiding space leaks at all costs
#2Wait, 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.
Re: Avoiding space leaks at all costs
#3Wait, 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.
Lazily evaluating 2+2 requires storing two numbers and an operator for a while, eagerly evaluating requires storing just one number (4, the result).
This can be a real problem, for example if you read potentially large network input eagerly and use it to compute a small result lazily. IMO it's always a mistake and IMNSHO the proper solution is always something more nuanced than just "make it eager" or "make it properly lazy".
Re: Avoiding space leaks at all costs
#4> 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.
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.
Re: Avoiding space leaks at all costs
#5> 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. 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 variou…
It is Haskell, just not Haskell2010. It is included in GHC2021.
Would you say that a company that uses a subset of C++ as a policy is not using C++? Their definition of the subset is as arbitrary as another’s that uses BangPatterns.
Re: Avoiding space leaks at all costs
#6> 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. 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 variou…
If our arguments can be so pedantic, then I can say: sure, Haskell is forever a research language. But that's irrelevant to me, because I use no-longer-really-Haskell.
Re: Avoiding space leaks at all costs
#7Wait, 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.
In all languages, sometimes you want eager evaluation and sometimes you want lazy evaluation.
If things are lazy by default, you simply need to put a "!" before the term to evaluate in order to get eagerness.
If things are eager by default, you need to rewrite the algorithm as a streaming algorithm.
Re: Avoiding space leaks at all costs
#8> 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. 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 variou…
It is Haskell, just not Haskell2010. It is included in GHC2021. Would you say that a company that uses a subset of C++ as a policy is not using C++? Their definition of the subset is as arbitrary as another’s that uses BangPatterns.
Sure, this language feature is mainstream now. But most real-world haskell codbases vary greatly in which language extensions they've chosen to use.
Re: Avoiding space leaks at all costs
#9I 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.
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).
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?
Re: Avoiding space leaks at all costs
#10> all mainstream languages have eager evaluation models
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.