Возможные исключения
- При пустом списке: $f[]$ приводит к исключению из-за $head[]$ — сообщение «Prelude.head: empty list».
- При списке из одного элемента: $f[x]$ — сначала $tail[x]=[]$, затем $head(tail[x])=head[]$ => «Prelude.head: empty list».
- Если какой‑то элемент списка является «⊥» (undefined, бесконечный цикл и т.п.), то при попытке его взятия будет бросено соответствующее исключение (например, $xs=[1,\perp ]$ => при вычислении второй компоненты исключение).
- Дополнительно возможны исключения, связанные с операцией сложения для конкретной реализации типа чисел, но обычные инстансы $Num$ для примитивов строгие и просто требуют значения аргументов.
Статическая типизация
- GHC выведет тип $f::Numa=>[a]->a$. Статическая типизация гарантирует, что вы не передадите в функцию несоответствующий тип (не‑список или элементы не‑числа), но она не проверяет длину списка. То есть типовая система не защищает от пустого/короткого списка — это динамическая (выполняемая) ошибка.
- Для устранения частичных функций и сделать поведение безопасным на уровне типов можно:
- Явно обрабатывать случай короткого списка (возвращать $Maybe$): $f::Numa=>[a]->Maybea;f(x:y{:}_{)}=Just(x+y);f_{=}Nothing.$ - Использовать структуры с гарантией непустоты ($Data.List.NonEmpty$) или более мощные системы типов (dependent types), чтобы статически гарантировать длину ≥ 2.
Ленивость и производительность
- Ленивость полезна: функция запрашивает только первые два элемента списка, поэтому работает с бесконечными списками (например, $f[\mathrm{1..}]$ корректно) и не вычисляет хвост списка.
- Однако операции извлечения через $head$ и $tail$ заставляют вычислять соответствующие элементы по мере необходимости. Операция $+$ для обычных числовых инстансов обычно строга в аргументах, поэтому оба первых элемента будут приведены к нужной нормальной форме перед сложением.
- С точки зрения производительности:
- Паттерн‑матч $(x:y{:}_{)}=$ обычно эффективнее и чище, чем использование $head$ и $tail$ (избегает дополнительных частичных функций и делает намерение очевидным).
- Ленивость может создавать промежуточные отложенные вычисления (thunks); при интенсивных числовых вычислениях полезно делать аргументы строгими (BangPatterns, seq или строгие поля) чтобы избежать накопления памяти.
- GHC часто оптимизирует простые случаи (инлайн, убирать лишние проверки), но явный паттерн‑матч всё равно рекомендован как более идиоматичный и предсказуемый.
Краткое резюме
- Риск — только рантайм‑ошибки при коротком списке или при «⊥» в элементах; статическая типизация защищает от несоответствия типов, но не от длины списка.
- Писать лучше через паттерн‑матч и, если нужно, возвращать $Maybe$ или использовать типы, гарантирующие непустоту; ленивость позволяет работать с бесконечными списками и экономить вычисления, но может потребовать явной строгой оценки для производительности.