было бы удобно в типе видеть что может произойти

в хаскеле это невозможно

Фича: пока меньше или равно - генерит, как станет больше - останавливается.

И как заменеджить это лучше, кроме как предварительной проверкой инкримента?

в хаскеле это невозможно

(

выразительности суммы типов недостаточно?

ну так обрабатывайте, вы ж в IO, никто не мешает

я к тому что это не кейс для броска ексцепшена

вполне кейс

@A64m_qb0 а для такого Applicative m => Maybe a -> e -> ExceptT e m a в линзах что есть?

так сразу не могу сказать

tryIO

вполне кейс

почему? разве не правильнее ошибки держать в результате и заставлять их обрабатывать?

в хаскеле для этого всё есть под рукой

нет, нету

да поясни

в хаскеле проверяемые экспешены невозможны

было бы удобно в типе видеть что может произойти

везде может произойти вообще что угодн

чего там выше очередные генерогенные рекорды?

любое значение может содержать любое исключение /thread

да поясни

https://simonmar.github.io/posts/2017-01-24-asynchronous-exceptions.html

+ асинхронные ещё

в хаскеле проверяемые экспешены невозможны

тоесть ексцепшены в такой ситуации это канонично и не рассматривается как изъян?

которые прилетуют в любой момент

а ещё Either пока тормозит

это вам не раст

unboxed sum types пока не довезли

тоесть ексцепшены в такой ситуации это канонично и не рассматривается как изъян?

да, это нормально, исключения это то что предполагается нормальным обрабатывать, это не error, который значит что программа неправильно написана

чего там выше очередные генерогенные рекорды?

пытаюсь generic осилить, но чет это слишком сложно

И как заменеджить это лучше, кроме как предварительной проверкой инкримента?

А чем плох бесконечный список в ленивом языке? И если-таки плох для какой-то предметной области, то откуда там нулевой инкремент берется?

да, это нормально, исключения это то что предполагается нормальным обрабатывать, это не error, который значит что программа неправильно написана

понятно, я думал что наоборот и думал что на эту тему есть история как такое получилось

ну окей конкаренси совсем боль. ну вот в сишке например возвращается null из fopen почему в хаскеле обязательно должен быть эксепшен

я просто не понимаю этого фатализма резкого

что мол спросили вполне конкретный вопрос, а вы такие резко в крайности ушли

мол мы ничего с этим поделать не можем - жизнь опасна и жестока

потому что уже в IO, в чистом коде есть смысл не исключения использовать, в IO уже нет, они просто удобнее будут

я вроде написал почему в haskell невозможно ловить все исключения

А чем плох бесконечный список в ленивом языке? И если-таки плох для какой-то предметной области, то откуда там нулевой инкремент берется?

Да ничем, но вот >Когда начало и конец интервала совпадают площадь должна равняться нулю. интегралы - интегральчики

более того нельзя перечислить все типы ошибок которые могут вернуться

2 раза написал минимум

но похоже это никому не интересно, т.к. мне не отвечали

ну ладно. я первый свернул тему не туда)

расширяемые исключения обычно удобнее чем Either

хотя я бы честно хотел видеть какие-то аннотации

типа функция может бросить вот это вот, и может что-то ещё

я так понял, если есть class C a b | a -> b type family F a b :: Constraint то сделать instance F a b => C a b не получится, так как в F нет некой выводимости b из a (lhs type 'a' do not jointly determine rhs type ‘b’)

просто с EItherT все быстро печально становится

и толку нету все равно

експириенс с обработкой ексцепшенов в хаскеле это одна из причин быстрого падения моей воодушевлённости к хаскелю после прочтения LYAH и написания первых програм

а чего их ловить то?

експириенс с обработкой ексцепшенов в хаскеле это одна из причин быстрого падения моей воодушевлённости к хаскелю после прочтения LYAH и написания первых програм

далее попробуй вектора и конкаренси с пробиванием эксепшенов из одного потока в другой

да вроде как везде: в эффектном коде try/catch, в чистом either/except со своими try/catch

Да ничем, но вот >Когда начало и конец интервала совпадают площадь должна равняться нулю. интегралы - интегральчики

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

а чего их ловить то?

1. когда "исключительная ситуация" это ожидаемая ситуация в моей програме 2. показать нормальное сообщение об ошибке вместо хаскелевского стактрейса

а смысле в чем сложность с этим?

у меня с catch получалось дико уродливая конструкция которую я ещё долго соображал как сделать

ну это как спрашивать в чём проблема писать без типов ты не знаешь наверняка захендлился эксепшен где-то во вложенных функциях или нет

(хотя лол - я сам же за сегодня дважды написал Left e -> error $ show e)

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

Логично. но все же, как тогда лучше, просто ветвление?

у меня с catch получалось дико уродливая конструкция которую я ещё долго соображал как сделать

*catches простой case там был бы проще и понятнее

Да ничем, но вот >Когда начало и конец интервала совпадают площадь должна равняться нулю. интегралы - интегральчики

ну кстати ты наверное должен же задать интеграл как (x1 - x0) * (f(x1) - f(x0))

Логично. но все же, как тогда лучше, просто ветвление?

Тут, полагаю, да.

*catches простой case там был бы проще и понятнее

для этого есть try

с интегралами, почему не (b-a)/n?

чтобы ошибку то не накапливать

и потом [0..n] и все

*catches простой case там был бы проще и понятнее

ну или (b-a)/delta

если хочется так по немногу, то проще уже врапперы написать конечно

или так

осилил генерик, красота в прод такое тащить нельзя конечно https://gist.github.com/kana-sama/b7f8a2a405061260a2ee7beafbd59e32

ну или (b-a)/delta

кажется это численная производная ну и особо не понял про накопление ошибки точнее не помню как оно оценивается вроде деление всё равно даст гораздо больше ошибки (ну это интуитивно)

2 варианта, или фиксированная дельта, тогда делим конец - начало на дельту получаем число шагов

или фиксированное число шагов, тогда длину шага считаем

каждая операция с IEEE будет накапливать ошибку, если не использовать спец схемы

поэтому a+d+d+d+d....

будет не тоже самое что a+d*n, для какого-то n

@vlastachu ^

как правильно хендлить такой кейс? моя ситуация: есть тип, в который можно сетать, нужно научится сетать в (a :*: b) в нужную ветку в зависимости от того, в какую можно сетать

каждая операция с IEEE будет накапливать ошибку, если не использовать спец схемы

мм ну ок

@kana_sama что если оба?

ветки

предположительно в обе не получится, но не уверен, что компилятору можно об этом сказать