Thunks, Sharing, Laziness: The Haskell Heap Visualized - Joachim Breitner

Haskell is a high-level, declarative language that frees you from worrying about how your programs are actually executed, and that is a good thing. Nevertheless, it can be quite useful to know how things work under the hood.
In his talk, our guest speaker Joachim takes you on a tour to the heap of a running Haskell program, where you’ll get to see the shape of data types, observe sharing and laziness, distinguish infinite and cyclic data structures, and watch a lazy tree grow as a recursive function gets memoized.
FP merch that doesn't suck 👇
shop.serokell.io/
Follow on social media:
/ nomeata
/ serokell
Learn more about us:
serokell.io/
Contact us:
[e-mail]
Timeline:
0:00 Introduction
0:38 Setting up ghc-vis
2:22 Simple data structures
7:15 Lists
9:16 Sharing in lists
12:18 Laziness
27:50 Cyclic data structures
36:30 How to use laziness for memoization

[@jonnmostovoy2406]

I wish this talk existed ten years ago. Thank you so much, Joachim for being our guest!

[@JesstyEissej]

That cyclic vs infinite list is a very neat trick, I had no idea!

Thanks, this is great! Though i wish you had also looked at how space leaks look like/happen on the heap.

[@ycombinator765]

I LOVE HIS SHIRT!

[@kahnfatman]

I can perfectly visualize and understand why Haskell could consume a large chunk of memory. Haskell's laziness is a blessing and a curse at the same time. I mean the language surely is not suitable for system programming where memory is limited but correctness is the critical prize to achieve at all cost.

[@shutterrecoil]

19:10 nice example why index operation is danger "l !! 4" is fifth element.

[@takumicrary4396]

Thank you!

[@burnytech]

Good stuff

[@chillidog8726]

This memorisation is really cool but I remember using haskell arrays for dynamic programming haskell back in uni
which should still be faster then running over the index tree with access speed of log n
but why would you or should you use trees or/vs arrays(O(1) access) in such a manner or am I not understanding sth correctly

[@smarthumanism3221]

But this is done in interactive mode. I have thought haskell in runtime doesn't contain all the meta data including constructor, but only compilers know and deal with it in compile time. Is there anybody who knows which is right?

[@monadplus]

In Haskell, type-erasure happens during code generation in contrast to e.g java where objects have metadata associated to them available at runtime. You can still access type info with type classes like Data.Typeable and Data.Data, but you must be explicit about it. I think what we see here is debug information added by ghci (idk about specifics). Executables with profiling on preserve type info that can be collected at runtime on the prof files. Not sure about regular builds.
Disclaimer: I am not an expert in ghc, so take it with a grain of salt.

[@shutterrecoil]

Wow GHC deduplicate and reuse small objects (aka flyweight pattern). Is it possible to turn the feature off? What impact on high concurrent environment with lots of threads? JVM has similar feature string reduplication, but it is usually deactivated, because of races.

[@rose123998]

AAAAAAAAamzaing

[@shutterrecoil]

Why Nothing pointer is not 0 but a dangling address?!

[@SgtMacska]

To distinguish it from the [] pointer?

[@JordiMontesSanabria]

Uninitiated memory I guess

[@tricky778]

If it's so simple to decide that it's correct to ignore the svgcairo problem that it can be done without justification, why does cabal need me to tell it to do that? If it's not so simple to decide, why would I go ahead and do it?

[@nomeata]

The justification is that it builds 😃
But yes, you are right that some of this is unnecessarily hard. I hope things will improve over time here.

[@tricky778]

@@nomeata the evidence to date is that it doesn't improve