Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Avoiding space leaks at all costs

kodimensional.dev

Post reply on HN
Print view View original

21–30 of 47 posts

Re: Avoiding space leaks at all costs

#21

Post by Joker_vD »

mrkeen wrote: post #7
MauranKilom wrote: post #2

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.

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.

> you simply need to put a "!" before the term to evaluate in order to get eagerness

That's wrong. With the bang pattern, evaluation only goes up to WHNF, not the whole way — it's just a syntax sugar around "seq" which has been around since always. If you need to fully evaluate the term, look at the deepseq package: it's implementation is non-trivial.

Re: Avoiding space leaks at all costs

#22

Post by tialaramex »

kzrdude wrote: post #11
eptcyka wrote: post #8

Earlier quoted context omitted.

Sure, this language feature is mainstream now. But most real-world haskell codbases vary greatly in which language extensions they've chosen to use.

Is this a C++ benefit, that the competing implementations GCC and LLVM give each other's extensions to the language more legitimacy by having a second implementation? It doesn't seem like language extensions get so much attention in C++ codebases (but maybe I'm mistaken)?

C and C++ programmers who write only or mostly for a single platform often have some extensions they insist on, and may even regard the standard language (lacking these features) as defective.

Linux won't compile in MSVC. Obviously it needn't, it's a kernel and not a Windows program, but it also can't, because it needs GNU extensions, which are now also implemented for Clang.

If you write broadly cross platform software for C++ you are committed to supporting all three compilers and so that's effectively just the standard. Indeed if all three do or don't do something de facto that is the standard. The ISO document used to say C++ has optional garbage collection, it doesn't because none of the three compilers have that. The ISO standard still doesn't say pointer provenance is a thing, but all three compilers require it, so in fact it's a thing.

Re: Avoiding space leaks at all costs

#23

Post by shirogane86x »

cvoss wrote: post #14
mrkeen wrote: post #7

Earlier quoted context omitted.

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.

There's no inherent reason why doing lazy evaluation in an eager-by-default language should be any harder than the reverse. I can imagine a language that is eager by default but has a '#' operator that holds expressions in unevaluated form until terms are requested.

Sadly even though what you say is true, I do not know of any languages that get that right. Even those that do care enough to give you a way to make lazy values, they require you to explicitly wrap them and force them all over the place, making lazy programming effectively so noisy it's unusable. Which is the main reason why I still find myself coming back to haskell (stuff like parser combinators is just so unwieldy without laziness and do notation...)

Re: Avoiding space leaks at all costs

#24

Post by benreesman »

UncleMeat wrote: post #19
benreesman wrote: post #16

Earlier quoted context omitted.

GHC language extensions are like C++ Technical Reports. They are a way to evolve the language without excessive red-tape on an opt-in basis, and periodically the ones that worked out make it into a new “standard”. It’s not really all the different from Python PEPs or Rust’s various proposals / nightly stuff. Just about every language has some form of this.

That's true. And when somebody says "oh you can just use GCC's special feature to make C++ tolerable" they rightly get pushback because only a portion of these features ever make it into a standard. This means that over time you end up with a codebase that is forever tied to these nonstandard features and might even end up being incompatible with major language changes. Or maybe the feature you adopted does get stand…

Just about every successful C/C++ project uses flags or intrinsics or whatever to some degree. It’s not unusual or particularly problematic. Linux famously uses a bunch of GCC stuff (though I gather that’s in decline) and non-standard defaults like ‘-fno-strict-aliasing’.

And the extensions in the article are for the most part in the GHC2021 standard. So it’s more like, this is in C++20.

Younger languages like Rust or Kotlin or something have less pressure for mechanisms like this because you have to get to a certain point in the language lifecycle before the tradeoff tilts from “let’s do a breaking change at a point release” to “let’s flag in the new behavior”, but if (as I expect) e.g. Rust lasts as long as C++ or Haskell, it will be be bedazzled with all kinds of flags and extensions and stuff too, how else do you grow a language for 40 years?

Re: Avoiding space leaks at all costs

#26

Post by assbuttbuttass »

userbinator wrote: post #25

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.

It's the equivalent of "memory leak" for a garbage-collected language

Re: Avoiding space leaks at all costs

#27

Post by MauranKilom »

shirogane86x wrote: post #23
cvoss wrote: post #14

Earlier quoted context omitted.

There's no inherent reason why doing lazy evaluation in an eager-by-default language should be any harder than the reverse. I can imagine a language that is eager by default but has a '#' operator that holds expressions in unevaluated form until terms are requested.

Sadly even though what you say is true, I do not know of any languages that get that right. Even those that do care enough to give you a way to make lazy values, they require you to explicitly wrap them and force them all over the place, making lazy programming effectively so noisy it's unusable. Which is the main reason why I still find myself coming back to haskell (stuff like parser combinators is just so unwieldy…

Counterpoint: C++ expression templates have existed for a long time, and require no explicit work on the user side. They are incredibly unwieldy to write and debug though.

Re: Avoiding space leaks at all costs

#28

Post by shirogane86x »

MauranKilom wrote: post #27
shirogane86x wrote: post #23

Earlier quoted context omitted.

Sadly even though what you say is true, I do not know of any languages that get that right. Even those that do care enough to give you a way to make lazy values, they require you to explicitly wrap them and force them all over the place, making lazy programming effectively so noisy it's unusable. Which is the main reason why I still find myself coming back to haskell (stuff like parser combinators is just so unwieldy…

Counterpoint: C++ expression templates have existed for a long time, and require no explicit work on the user side. They are incredibly unwieldy to write and debug though.

I am gonna be completely honest, I have never quite been able to understand expression templates properly. is it possible to use them to get hassle-free laziness? is there any example of a library that does this (just to look at it and see how it's done)?

Re: Avoiding space leaks at all costs

#29

Post by derefr »

tialaramex wrote: post #22
kzrdude wrote: post #11

Earlier quoted context omitted.

Is this a C++ benefit, that the competing implementations GCC and LLVM give each other's extensions to the language more legitimacy by having a second implementation? It doesn't seem like language extensions get so much attention in C++ codebases (but maybe I'm mistaken)?

C and C++ programmers who write only or mostly for a single platform often have some extensions they insist on, and may even regard the standard language (lacking these features) as defective. Linux won't compile in MSVC. Obviously it needn't, it's a kernel and not a Windows program, but it also can't, because it needs GNU extensions, which are now also implemented for Clang. If you write broadly cross platform softw…

> The ISO document used to say C++ has optional garbage collection

I'm intrigued; what was this feature supposed to look like?

Re: Avoiding space leaks at all costs

#30

Post by koala_man »

benreesman wrote: post #18
skywhopper wrote: post #9

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. 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, th…

Some would argue that in retrospect strict should have been the default, I sympathize with that view personally somewhat. But every language that beats Darwin for long enough does so by iterating the stuff that can be “fixed” and developing conventions and tools for the gotchas that can’t (practically) be.

I would love a strict Haskell, but I don't think functional programming would have been the same today. Laziness was the big motivator for keeping the language uncompromisingly pure, and we may not have developed monads and similar without it.
Post reply on HN