Skip to content
0:00 / 0:00

#haskell#laziness#space-leaks

MuniHac 2020: Edsko de Vries - Being lazy without being bloated

TNG Technology Consulting GmbH

5K subscribers • 14 videos on Hallway

YouTube
  • Recommended by 1 person: 1 in engineering communities.
  • Presented by Edsko de Vries

Advanced. Deep dive for people who know the field.

1K views6 years ago1 recommendation

Programming languagesSystems programmingHaskellPerformance and optimizationTesting

Edsko de Vries discusses Haskell's laziness, space leaks, and introduces the nothunks library for testing the absence of unexpected thunks.

Title: Being lazy without being bloated Speaker: Edsko de Vries Laziness is one of Haskell's most distinctive features. It is one of the two features of functional programming that "Why Functional Programming Matters" identifies as key to modularity, but it is also one of the most frequently cited features of Haskell that programmers would perhaps like to change. One reason for this ambivalence is that laziness can give rise to space leaks, which can sometimes be fiendishly difficult to debug. In this talk we will present a new library called 'nothunks' which can be used to test for the absence of unexpected thunks in long-lived data; when an unexpected thunk is found, a "stack trace" is returned identifying precisely where the thunk is ("the second coordinate of a pair in a map in a list in type T"). In combination with QuickCheck, this can be used to test that an API does not create any thunks when it shouldn't and thunks that are created are easily identified and fixed. Whilst it doesn't of course fix all space leaks, it can help avoid a significant proportion of space leaks due to excessive laziness. MuniHac 2020, September 11 / munihac.de/ TNG Technology Consulting GmbH / tngtech.com

Why it's here

1 person recommends this

What people say. Recommended as an excellent talk on debugging space leaks and testing for unexpected thunks in Haskell.

u/Hjullein r/haskell • Recommends

Automatically statically check if a data type is fully strict or not I was inspired by a question at the end of the Being lazy without being bloated presentation about the library nothunks, which asked if it was possible to do the same check statically. I managed to come up with a type class `IsStrict` which will give a type error if there is a non-strict field anywhere, at any depth, in the data structure given, explaining where the non-strict field is. Here it is in a gist: https://gist.github.com/anka-213/440cfef8c8712f5df747029640cfe170 For example, if one were to ask if `String` is strict, it would give this error: ``` Found lazy field of type Char • In constructor: : • In type:…