Здравствуйте, korvin_, Вы писали:
_>Вот интересно, а что вы делаете в Java при получении OOM?
Смотря какой код у меня исполняется. Есть применения, где при получении OOM мне нужно не просто 500 Internal Error, а успеть сделать что-то полезное (например, сохранить стейт воркфлоу) перед тем, как умереть.

_>Там написано не про это. Насчёт does not uglify the calling code я бы поспорил.
Другого описания работы исключений в haskell я не нашёл.

_>А что вы предлагаете делать при OOM?
Много что можно сделать, особенно если озаботиться заранеешным созданием объектов, которые потребуются для обработки OOM. Например, можно урезать осетра и попробовать продолжить с буфером меньшего размера (хоть и медленнее).

_>Это алгебраический тип, но при чём тут это?
То, что OOM могло бы быть одним из его слагаемых.

_>И что с ним делать в Expr? Давайте добавим. Как это отразится на expr0? Что вообще дальше делать с этим OOM?
Обрабатывать или прокидывать.
Ну, вот что нам делать с None в Optional<T>? Как замена int на Maybe<int> отразится на арифметике? Всё зависит от того, как сделан лифтинг в языке — автоматически, монадически, или никак.

_>Где бы он был в Java?
В Java он бы вылетел в виде unchecked exception. В воображаемой Java без исключений, но с not-nullable reference типами мы могли бы заставить new возвращать не T, а T?. В воображаемой Java с алгебраическими типами и наследованием мы могли бы заставить new T возвращать не T, а T | Error, и для общения с кодом, который требует чистый T этот результат пришлось бы очищать.


_>Нет, там какая-то чёрная магия с примитивами: https://hackage.haskell.org/package/ghc-prim-0.13.0/docs/src/GHC.Prim.html#raise%23
Матерь божья и святые угодники!