Коротко: ленивость откладывает вычисления в виде отложенных выражений (thunks). Это экономит работу и память, когда результат не нужен, но может привести к накоплению thunks и удержанию больших объектов в памяти — «space leak». Ниже — типичные примеры и способы устранения.
1) Пример: накопление thunks при свёртке (foldl)
```haskell
import Data.List (foldl')
-- вызывает накопление thunks: build-up выражений (0 + 1) + 2 + ...
sumLazy :: Integer -> Integer
sumLazy n = foldl (+) 0 [1..n]
-- строгий вариант: не накапливает thunks
sumStrict :: Integer -> Integer
sumStrict n = foldl' (+) 0 [1..n]
main = do
let n = 10000000 -- большой n
print (sumLazy n) -- может упереться в память/стек
print (sumStrict n) -- держит память низкой
```
Объяснение: foldl строит цепочку отложенных сложений длины примерно $n$, в результате появляется большой thunk; foldl' применяет аккумулятор строго, поддерживая фиксированный объём памяти. Можно добиться строгого аккумулятора вручную с `seq` или с `{-# LANGUAGE BangPatterns #-}`.
2) Пример: lazy I/O — удержание дескриптора файла / всего содержимого
```haskell
import System.IO
-- Плохая практика: readFile даёт ленивое содержимое,
-- дескриптор файла может оставаться открытым до GC
bad :: IO Int
bad = do
contents <- readFile "bigfile.txt"
return (length (lines contents)) -- потребляет весь файл, но handle может быть открыт долго
-- Хорошая практика: читать строго или использовать withFile и принудительную оценку
good :: IO Int
good = withFile "bigfile.txt" ReadMode $ \h -> do
contents <- hGetContents h
let !len = length (lines contents) -- принудительно оцениваем до выхода из withFile
return len
-- Ещё лучше — стримить (conduit, pipes, streaming) или использовать Data.ByteString (strict) для контролируемого чтения.
```
Объяснение: ленивое `readFile` создаёт связь с дескриптором, и пока части содержимого остаются невычисленными, дескриптор не закроется — возможен leak. Решения: использовать `withFile`/`bracket` и полностью вычислить/записать результат внутри блока, либо читать строго (`Data.ByteString.readFile`) или использовать стриминг-библиотеки.
3) Другие причины space-leak и их устранение
- Удержание ссылки на начало коллекции: если вы сохраняете ссылку на голову списка и одновременно проходите его, GC не может освободить уже обработанные элементы. Решение: не держите лишние ссылки, используйте итеративные потребления (например `foldl'`, `mapM_`, стриминг).
- Ленивые поля в структурах данных: замените на строгие поля (`data Foo = Foo !Int !Text`) или используйте `{-# LANGUAGE StrictData #-}`.
- Непринудительные деревья/сложные структуры: использовать `deepseq` / `rnf` для глубокого принуждения, когда нужно освободить память сразу.
Как диагностировать
- Запускать программу с RTS: `+RTS -s` для сводки по памяти/времени.
- Использовать heap profiling (`-hr`, `-hc`) и инструменты GHC профилирования, `threadscope` и специализированные профайлеры.
- Внимательно смотреть стек вызовов и места, где создаются большие thunks.
Короткая памятка по исправлениям
- Для аккумуляторов: `foldl'`, `seq`, bang-паттерны.
- Для I/O: `withFile`/`bracket`, strict ByteString/Text или стриминг-библиотеки.
- Для структур: строгие поля, `deepseq`.
- Для сложных leak’ов: профилирование и удаление ненужных ссылок.
Если нужно — могу привести более детальный пример с командами компиляции/профилирования и реальными метриками для выбранного `n` (например $n=10^7$).