Haskell и обработка исключений.

о чем думали создатели хаскеля

mailto:создатели хаскеля

Это надо на английский переводить ...

Инкрементирую. В данный момент с этим же вожусь.

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

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

То есть ты предлагаешь запихнуть все вычисления в монаду ErrorT?

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

Нет уж, для целочисленных вычислений лучше nan ввести. Вычислять выражения в ErrorT — лучше, мне кажется, застрелиться, чем так жить.

бред.. нетотальные функции часто нужны, если дело не доходит до agda, а если доходит, то почему бы не использовать её. Для желающих чрезмерной безопасности есть модуль Safe.

Не ErrorT, а Either для не монадических функций и EitherT для монадических. Все просто, да и где сложность в арифметике с монадами/функторами ? Разве что в многословности.

в многословности, в том что у тебя лишний уровень indirection, в том, что у тебя компилятор нифига не сможет сделать примитивные значение где может. Нафига оно надо? Плюс пойдет куча решений,а какой Either делать Either String? Either Text? Either MyFooFunctionError? а потом извращаться их объединять и мапить др на друга?

:t a

Ну ладно, с чистыми вычислениями все ясно, там и правда не так все гладко. Но выбрасывать Exception в операциях ввода-вывода - это же нехорошо, ведь там нужно форсировать вычисление error (или пользоваться методом fail из IO) чтобы прекратить вычисление действия и не совершить следующее IO действие, даже если текущее вызвало исключение. Нужна же гарантия последовательности вычислений, а это монада. Я не прав ?

C Lazy IO так не выйдет. Думаю, что возможна, например, такая ситуация: файл успешно открыли, что-то прочитали, а к тому времени, как стало нужно прочитать ещё кусочек, диск сдох.

когда вообще включали error

Не путаешь с userError?

Либо я чего-то не понимаю, и выбрасывать ошибку - очень удобно и правильно

Если все-таки не путаешь, то можно конкретный пример, где это так злоупотреблено? А то, например, я не знаю как обрабатывать head [].

А то, например, я не знаю как обрабатывать head []

head :: [a] -> Maybe a

Не обязательно именно так, можно, скажем лифтить в пользовательскую монаду, где по вкусу определены соотвествующие fail. Есть пакет на hackage.

Проблема скорее в том, что нет единого подхода, а местами перекрывается.

head :: [a] -> Maybe a

Батенька, это уже не head. Никто не запрещает import Safe, где это удообно. Но предложенное решение может усложнить без особого профита.

И да, где связь-то между `error' и IO, ткните что ль.

И? Операция деления в любом случае имеет тип Fractional a => a -> a -> a

Ты отвечал на топик, он вбразывал про «целочисленное» постом выше. Затем он возразил в _своем_ контексте.

А попробуйте целочисленно на ноль поделить.

Не путаешь с userError?

Да, выше выяснилось, что ленивый error таки нужен, для оптимизаций и быстрого прототипирования. Нормальный чистый код конечно не выбрасывает error где попало, а использует Either или Maybe. А вот

fail :: IO a

ты что-то сильно путаешь или плохо описываешь - операции ввода вывода это IO, там и exception и error вывалится, исключение только try (return ioWithError) >>= id, но в данном случае нужно понимать, что делаешь и все последовательно. Если ты внутри IO создаешь ленивое вычисление, которое может свалиться, то тогда можно всегда сделать evaluate/deepseq, но это опять же не относится к IO. Можешь привести пример тут или juick, который кажется тебе кривым, чтобы убедиться, что мы друг друга до конца понимаем?

LazyIO не нужно!!!1111 http://okmij.org/ftp/Haskell/index.html#lazyIO-not-True

Это так, но из песни слово Prelude функции не выкинешь.

Prelude заслуживает того, чтобы быть выкинутой полностью, учебная либа не нужна:) lazy io на самом деле дает интересный функционал и удобные абстракции, при этом надо понимать где могут быть проблемы.

Prelude заслуживает того, чтобы быть выкинутой полностью, учебная либа не нужна:)

Тоньше надо

Мне б ваши проблемы, ребят...

Программистам на других языках возможно кажется, что хаскелеры решают надуманные и несущественные проблемы, но зачем тогда нужен хаскель, если не делать все правильно Just Completely ?

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

Ты прав в целом, но не прав в частностях.

Во-первых, C-функции вполне способны бросать исключения. Собственно, с точки зрения операционки C-функции от C++-функций не отличаются вообще ничем.

Во-вторых, далеко не всегда Either - правильный выход.

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

Посреди вывода функция может гавкнуться. По твоей идеологии она должна возвращать Either SomeException String. А вот фигушки, потому что при попытке сделать паттерн-матчинг по такому выводу придётся всосать в память всю строку целиком (дабы убедиться, что оно таки нигде не гавкнулось). А это, вполне возможно, приведёт к падению программы с ошибкой переполнения стека. Сам на такое наталкивался.

Правильный вариант в данном случае - возвращать (String, Maybe SomeException) - то есть, прочитанную часть плюс возможно возникшее исключение. Ещё более правильный путь - воспользоваться библиотекой conduit и превратить функцию в Source. Но никак не Either SomeException String.

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

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

Во-вторых, Either вариант ничем не уступает кондуитам, пример: если поток у тебя - это String, то функция возвращающая один элемент - это

Either SomeException Char

eitherMap :: (a -> b) -> [Either e a] -> [Either e b]
eitherFoldl :: (b -> a -> b) -> b -> [Either e a] -> Either e b
eitherGroup ... 

Ну во-первых, чтобы паттернматчить Either достаточно вычислить его только до конструктора

Да. И это потребует выбрать вход до конца. Ибо ошибка может произойти на последнем байте, и тогда вместо Left должен будет быть Right.

[Either e b]

Это не есть хорошо. Это намёк, что после ошибки выполнение может продолжиться.

Про Lazy IO я уже выше писал, кстати. Если я правильно понимаю, "функция, возвращающая строку, которая может гавкнуться" может быть только в IO.

Если я правильно понимаю, «функция, возвращающая строку, которая может гавкнуться» может быть только в IO.

Это, собственно, почему?

Лень думать. Контрпример?

['a','b','c','d','e','f',error «Oh shit»]

проясни мысль про Source, у тебя же в случае кондуитов есть Source m o, где o это или String или

type DataPack a = Either ErrorType a

в первом случае ты будешь как обычно бросать исключение, во втором поведение с рассматриваемой точки зрения не отличается от [Either ErrorType a]. При этом если бы source мог возвращать значения и преждевременно закрывать весь downstream с своим значением, то разница бы была, а так он может только закрыть downstream и он уже сам что-то вернет.

А мысль, про (a, Maybe SomeException) интересна.

любая нетотальная функция хотя бы head (filter something), или map (5/) и то и другое чистое и может фейлиться, и то и другое можно обернуть в безопасный тип, но Miguel правильно отметил, что это приведет к той проблеме, что нужно будет вычислить всю функцию, чтобы понять не сломалась ли она.

При этом если бы source мог возвращать значения и преждевременно закрывать весь downstream с своим значением, то разница бы была, а так он может только закрыть downstream и он уже сам что-то вернет.

Ну дык Source-то может быть с любой монадой. Например, это может быть Source (EitherT SomeException IO) o. Если мы спарим его с Sink-ом, который умеет сворачивать вход, не загрязняя память, то, по идее, должны получить вменяемый результат (надо будет попробовать, кстати). Соответственно, так как ConduitM - инстанс MonadTrans, Source сможет закрыть downstream любым действием из EitherT SomeException IO () - например, Left чтототам.

согласен, но если попробуешь и скинешь итоговой код, то будет совсем прекрасно.

module Test where
import Control.Monad (forM_)
import Control.Monad.Trans
import Control.Monad.Trans.Either
import Data.Conduit
import Data.Conduit.List (consume, fold)
megaSource :: Integer -> Source (EitherT Int IO) String
megaSource n = forM_ [1..n] $ \k -> if k >= n then lift (left 0) else yield (show n) -- шоп упало в самом конце
getOutput :: Monad m => Source m a -> m [a]
getOutput src = src $$ consume
isGood :: Integer -> IO Bool
isGood n = eitherT (const $ return False) (const $ return True) $ getOutput $ megaSource n
checkSum :: Monad m => Sink String m Int
checkSum = fold (\n str -> n + sum (map fromEnum str)) 0
sumConduit :: Integer -> IO (Maybe Int)
sumConduit n = eitherT (const $ return Nothing) (return . Just) $ megaSource n $$ checkSum

Наш Source выдаёт охрененной длины список строк в монаде EitherT Int IO (Int тут не в тему, можно было что угодно взять). Если мы заберём весь этот список и попытаемся его спаттерн-матчить (командой isGood $ 10^8), то ghci упадёт по нехватке памяти. Если же мы отправим его в Sink, который умеет сворачивать входной поток (командой sumConduit $ 10^8), то всё отработает, не расходуя слишком много памяти. Я для пробы запустил sumConduit $ 10^9 - работало охрененно долго, но выдало результат.

нужно будет вычислить всю функцию, чтобы понять не сломалась ли она.

Как я уже написал выше, это вовсе не обязательно. Если вычисление вида

vichislenie :: Either e a

eitherMap :: (a -> b) -> [Either e a] -> [Either e b]
eitherFoldl :: (b -> a -> b) -> b -> [Either e a] -> Either e b
eitherFilter :: (a -> Bool) -> [Either e a] -> [Either e a]

ну и так далее.

Для чистого кода это лучше, ибо позволяет детерминированно проводить вычисления без фейлов, и да, error - это примерно как undefined, согласен. Нужен чтобы либо помечать очевидные ошибки, требующие вмешательства программиста, либо для быстрого прототипирования. Чистый код бросать их не должен. Естественно есть исключения типа деления на ноль и head, которые просто не работают на некоторых данных, и программист должен это учитывать, то есть, если head выбрасывает ошибку, то это проблема программиста, а не пользователя.

То достаточно вычислить до слабой головной нормальной формы, чтобы понять, что перед тобой Left или Right.

пусть foo :: String, bar :: String -> Either e a если мы делаем

case bar foo of
  Left .. -> ...
  Right .. -> ...

Про второе - да можно, а функции вида это mapM, filterM, fodlM над Either e.

про остальное - да.

Ты имеешь в виду, если a - рекурсинвый тип данных, типа списка или дерева, и может быть вычислен лишь частитчно ? Ну в этом случае операцию работающую с этим значением можно втянуть в само Either вычисление с помощью

eitherFoldl :: (b -> a -> b) -> b -> [Either e a] -> Either e b

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

Кое где кроме error есть еще и warning

И как он участвует в обработке ошибок ?

выводит сообщение о модуле и ошибке, и все работает дальше, если сможет (это матлаб)