[4] Кодирование ASCII преобразует файлы двоичных данных в простые печатные символы ASCII, тем самым обеспечивая кросс-платформенное соответствие. Преобразование из двоичного в обычный текст увеличивает размер исходного файла на несколько порядков.

Разбирать, не проверять

05.11.2019 ⦿ функциональное программирование, haskell, типы

Исторически сложилось так, что я изо всех сил пытался найти краткий и простой способ объяснить, что значит практиковать дизайн, управляемый типами. Слишком часто, когда кто-то спрашивает меня: «Как вы пришли к такому подходу?» Я обнаружил, что не могу дать им удовлетворительный ответ. Я знаю, что это не просто пришло ко мне в видении — у меня итеративный процесс проектирования, который не требует выхватывания «правильного» подхода из воздуха — и все же мне не очень удалось донести этот процесс до других. .

Однако около месяца назад я размышлял в Твиттере о различиях, с которыми столкнулся при синтаксическом анализе JSON в языках со статической и динамической типизацией, и, наконец, понял, что искал. Теперь у меня есть один броский слоган, отражающий, что для меня значит дизайн, основанный на шрифтах, и, что еще лучше, он состоит всего из трех слов:

Анализировать, не проверять.

Суть шрифтового дизайна

Хорошо, признаюсь: если вы еще не знаете, что такое шрифтовой дизайн, мой броский слоган, вероятно, не так уж много значит для вас. К счастью, именно для этого и предназначена оставшаяся часть этого сообщения в блоге. Я собираюсь объяснить, что именно я имею в виду, в кровавых подробностях, но сначала нам нужно немного попрактиковаться в принятии желаемого за действительное.

Царство возможного

Одна из замечательных особенностей систем статического типа заключается в том, что они позволяют, а иногда даже легко отвечать на такие вопросы, как «Возможно ли написать эту функцию?» В качестве крайнего примера рассмотрим следующую сигнатуру типа Haskell:

 foo :: Integer -> Void 

Можно ли реализовать foo ? Тривиально ответ нет , так как Void — это тип, который не содержит значений, поэтому для 9 это невозможно.0003 любая функция для получения значения типа Void . ¹ Этот пример довольно скучный, но вопрос становится намного интереснее, если мы выберем более реалистичный пример:

 head :: [a] -> a 

Эта функция возвращает первый элемент из списка. Возможно ли реализовать? Звучит конечно не так, как будто он делает что-то очень сложное, но если мы попытаемся это реализовать, то компилятор не удовлетворится:

 head :: [a] -> a
голова (х:_) = х 

 предупреждение: [-Wincomplete-шаблоны]
    Совпадения с образцом не являются исчерпывающими
    В уравнении для «головы»: Образцы не совпадают: []
 

Это сообщение полезно указывает на то, что наша функция является частичной , то есть она не определена для всех возможных входных данных. В частности, он не определен, когда ввод [] пустой список. Это имеет смысл, так как невозможно вернуть первый элемент списка, если список пуст — возвращаемого элемента нет! Итак, что примечательно, мы узнаем, что эту функцию также невозможно реализовать.

Вращение частичных функций всего

Для человека, работающего с динамически типизированным фоном, это может показаться запутанным. Если у нас есть список, мы вполне можем захотеть получить в нем первый элемент. И действительно, операция «получение первого элемента списка» не является невозможной в Haskell, просто требует небольшой дополнительной церемонии. Есть два разных способа исправить функцию головки , и мы начнем с самого простого.

Управление ожиданиями

Как установлено, head является частичным, потому что нет элемента для возврата, если список пуст: мы дали обещание, которое не можем выполнить. К счастью, у этой дилеммы есть простое решение: мы можем ослабить наше обещание. Поскольку мы не можем гарантировать вызывающей стороне элемент списка, нам придется немного попрактиковаться в управлении ожиданиями: мы сделаем все возможное, чтобы вернуть элемент, если сможем, но мы оставляем за собой право вообще ничего не возвращать. В Haskell мы выражаем эту возможность с помощью Может быть type:

 head :: [a] -> Maybe a 

Это дает нам свободу, необходимую для реализации head — это позволяет нам вернуть Ничего когда мы обнаружим, что не можем произвести значение типа a в конце концов:

 head :: [a] -> Maybe a
голова (x:_) = Просто x
head [] = Ничего 

Проблема решена, верно? На данный момент да… но у этого решения есть скрытая стоимость.

Возвращение Может быть, несомненно удобен, когда нам реализация головка . Однако он становится значительно менее удобным, когда мы действительно хотим его использовать! Поскольку head всегда может вернуть Nothing , бремя обработки этой возможности ложится на его вызывающих, и иногда такая передача ответственности может быть невероятно неприятной. Чтобы понять почему, рассмотрим следующий код:

 getConfigurationDirectories :: IO [FilePath]
getConfigurationDirectories = сделать
  configDirsString <- getEnv "CONFIG_DIRS"
  пусть configDirsList = разделить ',' configDirsString
  когда (нулевой configDirsList) $
    throwIO $ userError "CONFIG_DIRS не может быть пустым"
  чистый configDirsList
главная :: IO ()
главное = делать
  configDirs <- getConfigurationDirectories
  case head configDirs of
    Просто cacheDir -> initializeCache cacheDir
    Ничего -> ошибка "никогда не должна происходить; уже проверенные configDirs не пусты" 

Когда getConfigurationDirectories получает список путей к файлам из среды, он заранее проверяет, не пуст ли этот список. Однако когда мы используем head в main для получения первого элемента списка, результат Maybe FilePath по-прежнему требует от нас обработки случая Nothing , который, как мы знаем, никогда не произойдет! Это ужасно плохо по нескольким причинам:

1. Во-первых, это просто раздражает. Мы уже проверили, что список не пуст, зачем нам загромождать наш код еще одной избыточной проверкой?

2. Во-вторых, это потенциально снижает производительность. Хотя стоимость избыточной проверки в этом конкретном примере тривиальна, можно представить более сложный сценарий, в котором избыточные проверки могут суммироваться, например, если они происходят в замкнутом цикле.

3. Наконец, что хуже всего, этот код является ошибкой, ожидающей своего появления! Что, если бы getConfigurationDirectories были изменены, чтобы остановить проверку того, что список пуст, преднамеренно или непреднамеренно? Программист может не помнить об обновлении main , и вдруг «невозможная» ошибка становится не только возможной, но и вероятной.

Необходимость в этой избыточной проверке, по сути, вынудила нас пробить дыру в нашей системе типов. Если бы мы могли статически доказать случай Nothing невозможно, то модификация getConfigurationDirectories , которая прекращает проверку того, был ли список пустым, сделает доказательство недействительным и вызовет сбой времени компиляции. Однако, как написано, мы вынуждены полагаться на набор тестов или ручную проверку, чтобы обнаружить ошибку.

Платить вперед

Очевидно, что наша модифицированная версия головы оставляет желать лучшего. Как-то хотелось бы поумнее: если мы уже проверили, что список не пуст, head должен безоговорочно вернуть первый элемент, не заставляя нас обрабатывать заведомо невозможный случай. Как мы можем сделать это?

Давайте еще раз посмотрим на исходную (частичную) сигнатуру типа для head :

 head :: [a] -> a 

В предыдущем разделе показано, что мы можем превратить эту сигнатуру частичного типа в полную, ослабив обещание, сделанное в возвращаемом типе. Однако, поскольку мы не хотим этого делать, остается изменить только одно: тип аргумента (в данном случае [a] ). Вместо того, чтобы ослаблять возвращаемый тип, мы можем усилить тип аргумента, исключив возможность того, что head когда-либо будет вызвана для пустого списка.

Для этого нам нужен тип, представляющий непустые списки. К счастью, существующие 9Тип 0235 NonEmpty из Data.List.NonEmpty именно такой. Он имеет следующее определение:

 data NonEmpty a = a :| [a] 

Обратите внимание, что NonEmpty a на самом деле просто кортеж из a и обычного, возможно пустого [a] . Это удобно моделирует непустой список, сохраняя первый элемент списка отдельно от конца списка: даже если компонент [a] равен [] , компонент a всегда должен присутствовать. Это составляет head совершенно тривиально реализовать: ²

 head :: NonEmpty a -> a
head (x:|_) = x 

В отличие от предыдущего, GHC принимает это определение без претензий — это определение всего , а не частично. Мы можем обновить нашу программу, чтобы использовать новую реализацию:

 getConfigurationDirectories::IO (NonEmpty FilePath)
getConfigurationDirectories = сделать
  configDirsString <- getEnv "CONFIG_DIRS"
  пусть configDirsList = разделить ',' configDirsString
  case непустой configDirsList of
    Просто nonEmptyConfigDirsList -> чистый nonEmptyConfigDirsList
    Ничего -> throwIO $ userError «CONFIG_DIRS не может быть пустым»
главная :: IO ()
главное = делать
  configDirs <- getConfigurationDirectories
  initializeCache (главный configDirs) 

Обратите внимание, что избыточная проверка в основной теперь полностью удалена! Вместо этого мы выполняем проверку ровно один раз, в getConfigurationDirectories . Он создает NonEmpty a из [a] , используя функцию nonEmpty из Data.List.NonEmpty , которая имеет следующий тип:

 nonEmpty :: [a] -> Maybe (NonEmpty a) 

Возможно, все еще там, но на этот раз мы справимся с Ничего 9Случай 0236 очень рано в нашей программе: прямо в том же месте, где мы уже выполняли проверку ввода. После того, как эта проверка прошла, у нас теперь есть значение NonEmpty FilePath , которое сохраняет (в системе типов!) знание того, что список действительно непуст. Другими словами, вы можете думать о значении типа NonEmpty a как о значении типа [a] плюс доказательство того, что список не пуст.

Путем усиления типа аргумента до head вместо того, чтобы ослабить тип его результата, мы полностью устранили все проблемы из предыдущего раздела:

• Код не имеет избыточных проверок, поэтому не может быть никаких накладных расходов на производительность.

• Кроме того, если getConfigurationDirectories изменится, чтобы прекратить проверку того, что список не пуст, его возвращаемый тип также должен измениться. Следовательно, main не сможет выполнить проверку типов, предупредив нас о проблеме еще до того, как мы запустим программу!

Более того, тривиально восстановить старое поведение head из нового, составив head с nonEmpty :

 head' :: [a] -> Maybe a
голова' = fmap голова.  nonEmpty 

Обратите внимание, что обратное , а не верно: невозможно получить новую версию head из старой. В целом, второй подход лучше по всем осям.

Сила синтаксического анализа

Вам может быть интересно, какое отношение приведенный выше пример имеет к заголовку этой записи в блоге. В конце концов, мы рассмотрели только два разных способа проверки того, что список не пуст, без синтаксического анализа. Эта интерпретация не является ошибочной, но я хотел бы предложить другую точку зрения: на мой взгляд, разница между проверкой и синтаксическим анализом почти полностью заключается в том, как сохраняется информация. Рассмотрим следующую пару функций:

 validateNonEmpty :: [a] -> IO ()
validateNonEmpty (_:_) = чистый ()
validateNonEmpty [] = throwIO $ userError "список не может быть пустым"
parseNonEmpty :: [a] -> IO (NonEmpty a)
parseNonEmpty (x:xs) = чистый (x:|xs)
parseNonEmpty [] = throwIO $ userError "список не может быть пустым" 

Эти две функции почти идентичны: они проверяют, пуст ли заданный список, и если это так, прерывают программу с сообщением об ошибке. Разница полностью заключается в типе возвращаемого значения: validateNonEmpty всегда возвращает () , тип, который не содержит информации, но parseNonEmpty возвращает NonEmpty a , уточнение типа ввода, которое сохраняет знания, полученные в системе типов. Обе эти функции проверяют одно и то же, но parseNonEmpty дает вызывающей стороне доступ к полученной информации, а validateNonEmpty просто отбрасывает ее.

Эти две функции элегантно иллюстрируют два разных взгляда на роль статической системы типов: validateNonEmpty достаточно хорошо подчиняется проверке типов, но только parseNonEmpty в полной мере использует его преимущества. Если вы понимаете, почему parseNonEmpty предпочтительнее, вы понимаете, что я имею в виду под мантрой «разбирать, а не проверять». Тем не менее, возможно, вы скептически относитесь к имени parseNonEmpty . Действительно ли анализирует что-либо или просто проверяет ввод и возвращает результат? Хотя точное определение того, что значит синтаксический анализ или проверка чего-либо, является спорным, я считаю, что parseNonEmpty — полноценный синтаксический анализатор (хотя и очень простой).

Подумайте: что такое синтаксический анализатор? На самом деле синтаксический анализатор — это просто функция, которая получает менее структурированный ввод и выдает более структурированный вывод. По своей природе синтаксический анализатор является частичной функцией — некоторые значения в домене не соответствуют никакому значению в диапазоне — поэтому все синтаксические анализаторы должны иметь некоторое представление об отказе. Часто на вход синтаксическому анализатору поступает текст, но это ни в коем случае не является обязательным требованием, и parseNonEmpty — превосходный синтаксический анализатор: он разбирает списки на непустые списки, сигнализируя о сбое, завершая программу сообщением об ошибке.

При таком гибком определении синтаксические анализаторы являются невероятно мощным инструментом: они позволяют выполнять проверки ввода заранее, прямо на границе между программой и внешним миром, и после того, как эти проверки были выполнены, их никогда не нужно проверять снова! Хаскеллеры хорошо осведомлены об этой силе и регулярно используют множество разных типов парсеров:

• Библиотека aeson предоставляет тип Parser , который можно использовать для анализа данных JSON в доменных типах.

• Аналогично, optparse-applicative предоставляет набор комбинаторов синтаксического анализа для анализа аргументов командной строки.

• Библиотеки баз данных, такие как постоянные и postgresql-simple, имеют механизм анализа значений, хранящихся во внешнем хранилище данных.

• Экосистема слуг построена на разборе типов данных Haskell из компонентов пути, параметров запроса, заголовков HTTP и многого другого.

Общим для всех этих библиотек является то, что они находятся на границе между вашим приложением Haskell и внешним миром. Этот мир говорит не в типах произведения и суммы, а в потоках байтов, так что не обойтись без парсинга. Выполнение такого синтаксического анализа заранее, до обработки данных, может значительно помочь избежать многих классов ошибок, некоторые из которых могут даже быть уязвимостями в системе безопасности.

Одним из недостатков такого подхода к предварительному анализу всего является то, что иногда требуется анализировать значения задолго до их фактического использования. В языке с динамической типизацией это может затруднить синхронизацию логики синтаксического анализа и обработки без обширного покрытия тестами, многие из которых могут быть трудоемкими в обслуживании. Однако со статической системой типов проблема становится на удивление простой, как показано на примере 9.0235 NonEmpty Пример выше: если логика синтаксического анализа и обработки не синхронизирована, программа даже не скомпилируется.

Опасность валидации

Надеюсь, к этому моменту вы хотя бы частично уверились в том, что синтаксический анализ предпочтительнее валидации, но у вас могут остаться сомнения. Действительно ли валидация настолько плоха, если система типов в любом случае заставит вас выполнять необходимые проверки? Может быть, отчет об ошибках будет немного хуже, но немного избыточной проверки не повредит, верно?

К сожалению, это не так просто. Специальная проверка приводит к явлению, которое теоретико-языковая область безопасности называет разбором дробовика . В статье 2016 года «Семь башен Вавилона: таксономия ошибок LangSec и способы их устранения» авторы дают следующее определение: поперек обработки кода — бросая на вход тучу проверок и надеясь, без всякого систематического обоснования, что тот или иной отловит все «плохие» случаи.

Далее они объясняют проблемы, присущие таким методам проверки:

Мгновенный анализ обязательно лишает программу возможности отклонять неверный ввод вместо его обработки. Запоздало обнаруженные ошибки во входном потоке приведут к тому, что некоторая часть недопустимых входных данных будет обработана, в результате чего состояние программы будет трудно точно предсказать.

Другими словами, программа, которая не анализирует все свои входные данные заранее, рискует воздействовать на допустимую часть входных данных, обнаруживая, что другая часть недействительна, и внезапно возникает необходимость откатить все изменения, которые она уже выполнила. чтобы сохранить последовательность. Иногда это возможно, например, откат транзакции в СУБД, но в целом это может быть невозможно.

Может быть не сразу очевидно, какое отношение разбор дробовика имеет к проверке — в конце концов, если вы делаете всю свою проверку заранее, вы снижаете риск разбора дробовика. Проблема в том, что подходы, основанные на проверке, чрезвычайно затрудняют или делают невозможным определение того, действительно ли все было проверено заранее или действительно могут произойти некоторые из этих так называемых «невозможных» случаев. Вся программа должна предполагать, что возбуждение исключения в любом месте не только возможно, но и регулярно необходимо.

Синтаксический анализ позволяет избежать этой проблемы, разделяя программу на две фазы — синтаксический анализ и выполнение — где сбой из-за недопустимого ввода может произойти только на первой фазе. По сравнению с этим набор оставшихся режимов отказа во время выполнения минимален, и с ними можно обращаться с необходимой осторожностью.

Анализ, а не проверка, на практике

До сих пор эта запись в блоге была чем-то вроде коммерческого предложения. «Ты, дорогой читатель, должен заниматься разбором!» он говорит, и если я сделал свою работу должным образом, по крайней мере, некоторые из вас проданы. Однако, даже если вы понимаете «что» и «почему», вы можете не чувствовать особой уверенности в том, «как».

Мой совет: сосредоточьтесь на типах данных.

Предположим, вы пишете функцию, которая принимает список кортежей, представляющих пары ключ-значение, и вдруг понимаете, что не знаете, что делать, если в списке есть повторяющиеся ключи. Одним из решений было бы написать функцию, которая утверждает, что в списке нет дубликатов:

 checkNoDuplicateKeys :: (MonadError AppError m, Eq k) => [(k, v)] -> m () 

Однако , эта проверка ненадежна: ее очень легко забыть. Поскольку его возвращаемое значение не используется, его всегда можно опустить, и код, который в нем нуждается, все равно будет проверять тип. Лучшее решение — выбрать структуру данных, которая запрещает дублирование ключей по своей конструкции, например, Карта . Настройте сигнатуру типа вашей функции, чтобы она принимала Map вместо списка кортежей, и реализуйте ее, как обычно.

После того, как вы это сделаете, сайт вызова вашей новой функции, скорее всего, не пройдет проверку типов, поскольку ему все еще передается список кортежей. Если вызывающему объекту было присвоено значение через один из его аргументов или если он получил его из результата какой-либо другой функции, вы можете продолжить обновление типа из списка до Map на всем пути вверх по цепочке вызовов. В конце концов, вы либо доберетесь до места, где создается значение, либо найдете место, где дубликаты действительно должны быть разрешены. В этот момент вы можете вставить вызов модифицированной версии checkNoDuplicateKeys :

 checkNoDuplicateKeys :: (MonadError AppError m, Eq k) => [(k, v)] -> m (Map k v) 

Теперь проверку нельзя опускать, так как ее результат действительно необходим для продолжения программы!

Этот гипотетический сценарий подчеркивает две простые идеи:

1. Используйте структуру данных, которая делает недопустимые состояния непредставимыми. Смоделируйте свои данные, используя наиболее точную структуру данных, какую только сможете. Если исключить конкретную возможность слишком сложно, используя кодировку, которую вы используете в настоящее время, рассмотрите альтернативные кодировки, которые могут более легко выразить интересующее вас свойство. Не бойтесь рефакторинга.

2. Поднимите бремя доказывания как можно дальше, но не дальше. Превратите свои данные в наиболее точное представление, которое вам нужно, как можно быстрее. В идеале это должно происходить на границе вашей системы, до того, как будут обработаны любых данных. ³

   Если одна конкретная ветвь кода в конечном итоге требует более точного представления части данных, проанализируйте данные в более точное представление, как только ветвь будет выбрана. Разумно используйте типы сумм, чтобы ваши типы данных отражали поток управления и адаптировались к нему.

Другими словами, пишите функции в представлении данных, которое вы хотите иметь, а не в представлении данных, которое вам дано. Затем процесс проектирования превращается в упражнение по преодолению разрыва, часто работая с обоих концов, пока они не встретятся где-то посередине. Не бойтесь итеративно корректировать части дизайна по ходу работы, так как вы можете узнать что-то новое в процессе рефакторинга!

Вот несколько дополнительных советов, расположенных в произвольном порядке:

• Пусть ваши типы данных влияют на ваш код, не позволяйте вашему коду управлять вашими типами данных. Избегайте искушения просто вставить Bool в запись где-нибудь, потому что это необходимо для функции, которую вы сейчас пишете. Не бойтесь рефакторить код, чтобы использовать правильное представление данных — система типов гарантирует, что вы покрыли все места, которые нужно изменить, и, скорее всего, избавит вас от головной боли позже.

• Обработка функций, возвращающих м () с глубоким подозрением. Иногда они действительно необходимы, так как могут выполнять обязательный эффект без значимого результата, но если основная цель этого эффекта — вызвать ошибку, вероятно, есть лучший способ.

• Не бойтесь анализировать данные в несколько проходов. Избегание парсерного анализа просто означает, что вы не должны воздействовать на входные данные до того, как они будут полностью проанализированы, а не то, что вы не можете использовать некоторые из входных данных, чтобы решить, как анализировать другие входные данные. Множество полезных парсеров являются контекстно-зависимыми.

• Избегайте денормализованного представления данных, особенно , если оно изменчиво. Дублирование одних и тех же данных в нескольких местах приводит к тривиально представимому недопустимому состоянию: места не синхронизируются. Стремитесь к единственному источнику истины.

  • Держите денормализованные представления данных за границами абстракции. Если денормализация абсолютно необходима, используйте инкапсуляцию, чтобы гарантировать, что небольшой доверенный модуль несет единоличную ответственность за синхронизацию представлений.

• Используйте абстрактные типы данных, чтобы сделать валидаторы «похожими» на парсеры. Иногда сделать недопустимое состояние действительно непредставимым просто непрактично, учитывая инструменты, предоставляемые Haskell, такие как обеспечение того, чтобы целое число находилось в определенном диапазоне. В этом случае используйте абстрактный newtype с интеллектуальным конструктором, чтобы «подделать» парсер из валидатора.

Как всегда, руководствуйтесь здравым смыслом. Вероятно, не стоит выбрасывать синглтоны и рефакторить все ваше приложение только для того, чтобы избавиться от одной единственной девятки.0235 ошибка «невозможно» звоните куда-нибудь — просто не забудьте относиться к этим ситуациям как к радиоактивному веществу, которым они являются, и обращайтесь с ними с соответствующей осторожностью. Если ничего не помогает, по крайней мере, оставьте комментарий, чтобы задокументировать инвариант для тех, кому нужно изменить код следующим.

Резюме, размышления и соответствующее чтение

Вот и все. Надеюсь, этот пост в блоге доказывает, что для использования преимуществ системы типов Haskell не требуется докторская степень и даже не требуется использование новейших и лучших языковых расширений GHC, хотя иногда они, безусловно, могут помочь! Иногда самым большим препятствием для использования Haskell в полной мере является простое знание того, какие варианты доступны, и, к сожалению, одним из недостатков небольшого сообщества Haskell является относительная нехватка ресурсов, которые документируют шаблоны проектирования и методы, которые стали общим знанием.

Ни одна из идей в этом сообщении не является новой. На самом деле основная идея — «написать полные функции» — концептуально довольно проста. Несмотря на это, мне невероятно сложно сообщать действенные и практические подробности о том, как я пишу код на Haskell. Легко потратить много времени на обсуждение абстрактных понятий, многие из которых весьма ценны!, не сообщая ничего полезного о процессе . Я надеюсь, что это небольшой шаг в этом направлении.

К сожалению, я не знаю очень много других ресурсов по этой конкретной теме, но я знаю один: я никогда не колеблясь рекомендую фантастический пост в блоге Мэтта Парсона Type Safety Back and Forth. Если вам нужен другой доступный взгляд на эти идеи, включая еще один работающий пример, я настоятельно рекомендую прочитать его. Для значительно более продвинутого взгляда на многие из этих идей я также могу порекомендовать статью Мэтта Нунана 2018 года Ghosts of Departed Proofs, в которой описывается несколько методов для захвата более сложных инвариантов в системе типов, чем я описал здесь.

В заключение я хочу сказать, что рефакторинг, описанный в этом блоге, не всегда прост. Примеры, которые я привел, просты, но реальная жизнь зачастую гораздо менее прямолинейна. Даже для тех, кто имеет опыт проектирования, основанного на типах, может быть действительно трудно зафиксировать определенные инварианты в системе типов, поэтому не считайте личным провалом, если вы не можете решить что-то так, как вам хотелось бы! Считайте принципы, изложенные в этом блоге, идеалами, к которым нужно стремиться, а не строгими требованиями, которым необходимо соответствовать. Все, что имеет значение, это попробовать.

1. Технически, в Haskell игнорируются «днища», конструкции, которые могут занимать любое значение . Это не «настоящие» значения (в отличие от null в некоторых других языках) — это такие вещи, как бесконечные циклы или вычисления, вызывающие исключения — и в идиоматическом Haskell мы обычно стараемся их избегать, поэтому рассуждения, которые притворяются, что они не не существует по-прежнему имеет значение. Но не верьте мне на слово — я позволю Даниэльссону и др. убедить вас в том, что быстрое и расплывчатое мышление морально правильно. ↩

2. На самом деле Data.List.NonEmpty уже предоставляет функцию head с этим типом, но просто для иллюстрации мы перереализуем ее сами. ↩

3. Иногда необходимо выполнить какую-либо авторизацию перед анализом пользовательского ввода, чтобы избежать атак типа «отказ в обслуживании», но это нормально: авторизация должна иметь относительно небольшую площадь поверхности и не должна вызывать каких-либо значительных изменений в состояние вашей системы.