Size: a a a

2021 March 18

JS

Jerzy Syrowiecki in Haskell Start
Andrei Yangabishev
А, я понял. Такой объединяющий/объясняющий всё механизм, где мы нашей новой собственной монаде прописываем способность "генерить" исключения, а в catchError мы не паримся с pattern matching-ом, вообще ничего не знаем про внутреннее устройство этой новой монады (как в случае Either), а работаем с чистым исключением, а всю работу за нас делает instance монады. И Either это просто разновидность MonadError. И судя по instance MonadError IOException IO можно в IO монаде делать catch, а можно catchError ?
только это с pattern matching как-то перпендикулярно, или я вас не понял
источник

JS

Jerzy Syrowiecki in Haskell Start
Andrei Yangabishev
Блин, псевдоисключения еще. Новое понятие. Это имеется ввиду те, которые не наследуются от Exception, а произвольные, типа строки, числа, все что хочется?
если что "псевдоисключения" не настоящий термин, это я на ходу придумал, чтобы поменьше писать
источник

AY

Andrei Yangabishev in Haskell Start
Jerzy Syrowiecki
только это с pattern matching как-то перпендикулярно, или я вас не понял
Смысл в том, что если функция возвращает Either, то придется pattern matching делать, все эти Left/Right, а если возвращает :: MonadError String m => m Int, то нас перестает парить что там за монада, сегодня Either String Int возвращает, завтра ReaderT Env (Either String) Int, код снаружи от этого не поменяется ни для bind, ни для catchError (\(e::String) -> ...)
источник

JS

Jerzy Syrowiecki in Haskell Start
Andrei Yangabishev
Смысл в том, что если функция возвращает Either, то придется pattern matching делать, все эти Left/Right, а если возвращает :: MonadError String m => m Int, то нас перестает парить что там за монада, сегодня Either String Int возвращает, завтра ReaderT Env (Either String) Int, код снаружи от этого не поменяется ни для bind, ни для catchError (\(e::String) -> ...)
нет, не придётся. есть же instance Monad (Either a)
источник

AY

Andrei Yangabishev in Haskell Start
Jerzy Syrowiecki
нет, не придётся. есть же instance Monad (Either a)
О чем и речь. Только редко где этот подход из тех кодов что я видел используется. Видел мало конечно. Больше Either, Maybe используется. Хз с чем это связано.
источник

JS

Jerzy Syrowiecki in Haskell Start
именно в instance Monad (Either a) зашито поведение "аналог исключений"
источник

JS

Jerzy Syrowiecki in Haskell Start
Andrei Yangabishev
О чем и речь. Только редко где этот подход из тех кодов что я видел используется. Видел мало конечно. Больше Either, Maybe используется. Хз с чем это связано.
а в чём противоречие?
источник

JS

Jerzy Syrowiecki in Haskell Start
Either и Maybe используются не вопреки, а благодаря тому, что ими можно пользоваться как монадами и вместо исключений
источник

AY

Andrei Yangabishev in Haskell Start
Тогда я опять запутался.

1. Не вижу связи что Either это монада и как это связано с механизмом исключений. Механизм исключений для меня это тот ящик, на котором вроде бы написан тип, но внутри еще маленький ящик, в который кладется исключение и с этим маленьким ящиком работает вычислитель и исполнитель. Какое отношение к механизму исключений имеет факт что Either это монада со своими return/bind я не очень понимаю.
2. Вот это вот "благодаря" меня смущает, указывает на некую связь, какую-никакую. А по мне что Either, что исключения это совершенно разные механизмы и связи между ними нет. Можно Either использовать, можно throwError/catchError - вопрос вкуса. Строгих guideline я не видел пока.
источник

JS

Jerzy Syrowiecki in Haskell Start
Andrei Yangabishev
Тогда я опять запутался.

1. Не вижу связи что Either это монада и как это связано с механизмом исключений. Механизм исключений для меня это тот ящик, на котором вроде бы написан тип, но внутри еще маленький ящик, в который кладется исключение и с этим маленьким ящиком работает вычислитель и исполнитель. Какое отношение к механизму исключений имеет факт что Either это монада со своими return/bind я не очень понимаю.
2. Вот это вот "благодаря" меня смущает, указывает на некую связь, какую-никакую. А по мне что Either, что исключения это совершенно разные механизмы и связи между ними нет. Можно Either использовать, можно throwError/catchError - вопрос вкуса. Строгих guideline я не видел пока.
1. (>>=) реализован так, что Left прерывает вычисление/исполнение всего, что справа.

для меня это главное в абстрактном механизме исключений
источник

JS

Jerzy Syrowiecki in Haskell Start
а вычислитель, исполнитель и ящики, что были выше — это специфика IO
источник

AY

Andrei Yangabishev in Haskell Start
Jerzy Syrowiecki
1. (>>=) реализован так, что Left прерывает вычисление/исполнение всего, что справа.

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

JS

Jerzy Syrowiecki in Haskell Start
гайдлайны примерно такие:

если список исключений закрытый (нерасширяемый) и маленький, то лучше Either или что-то другое явное (ExceptT, MonadCatch...)

если исключения из внешнего мира (сеть, диск, ОС), если список открытый, то лучше throwIO, catch и документация
источник

JS

Jerzy Syrowiecki in Haskell Start
Andrei Yangabishev
А что первым появилось, Either или исключения? Ну да, Left прерывает, должен ли таким поведением обладать throwError, т.е. есть ли такой закон?
закона нет, но иначе просто невозможно реализовать. если нет значения a для запуска правой части байнда (>>) :: m a -> (a -> m b) -> m b, то она не будет запущена
источник

JS

Jerzy Syrowiecki in Haskell Start
Andrei Yangabishev
А что первым появилось, Either или исключения? Ну да, Left прерывает, должен ли таким поведением обладать throwError, т.е. есть ли такой закон?
появилось в Хаскеле? наверно, сумтипы и Either были с самого начала. IO с исключениями пришли позже
источник

JS

Jerzy Syrowiecki in Haskell Start
когда Хаскель начал использоваться в проде (около 2005 вроде), уже были все варианты обработки ошибок
источник

AY

Andrei Yangabishev in Haskell Start
Jerzy Syrowiecki
закона нет, но иначе просто невозможно реализовать. если нет значения a для запуска правой части байнда (>>) :: m a -> (a -> m b) -> m b, то она не будет запущена
А, ну да.
А вот еще вопрос. Evaluation же проходит на этапе работы программы и если с параллельного потока прилетит исключение, evaluation прервется или же нет и куда денется это исключение? Его только в IO можно будет отловить?
источник

JS

Jerzy Syrowiecki in Haskell Start
ещё есть в Хаскеле асинхронные исключения, котрые суть базовый механизм взаимодействия между нитями
источник

JS

Jerzy Syrowiecki in Haskell Start
Andrei Yangabishev
А, ну да.
А вот еще вопрос. Evaluation же проходит на этапе работы программы и если с параллельного потока прилетит исключение, evaluation прервется или же нет и куда денется это исключение? Его только в IO можно будет отловить?
да, всё так. прервётся и полетит в IO (есть тонкости с маскировкой)
источник

D

Dreamerinnoise in Haskell Start
Andrei Yangabishev
А, ну да.
А вот еще вопрос. Evaluation же проходит на этапе работы программы и если с параллельного потока прилетит исключение, evaluation прервется или же нет и куда денется это исключение? Его только в IO можно будет отловить?
на этот вопрос советую почитать Марлоу, его книгу
источник