Существует ли компилятор Haskell или препроцессор, который использует строгую оценку?

There have been two attempts at strictly evaluating Haskell in the past:

• Jan-Willem Maessen's Eager Haskell
• Rob Ennals PhD thesis

But both were focused on sticking to Haskell's non-strict semantics but using a mostly-strict evaluation strategy, rather than actually changing the semantics, and neither ever really saw the light of day.

Edit: Martijn's suggestion of strict-plugin looks ideal for your purposes as it actually does what you want and the author is still active in the Haskell community, I'd forgotten about it.

См. Также ghc-strict-plugin , пример для инфраструктуры подключаемых модулей GHC , описанный в Monad Reader 12 .

Я бы предпочел не ставить постоянно! s и $! s по всей моей программе

You ' Вы делаете это неправильно, если вы так программируете Haskell :) Вам просто не нужно этого делать. Используйте GHC, используйте -O2, используйте строгие типы данных, когда это необходимо, используйте ленивые, когда это необходимо. Не думайте, что лень станет проблемой - это решение многих проблем.

Я чувствую твою боль. Моя самая большая PITA в моем повседневном программировании связана с ними ! @Как типичный программист на Haskell, насколько вы зависите от ленивого вычисления.

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

Я не думаю, что это что-то новое; Я уверен, что другие языки и архитектуры тоже прошли через это. Как же, в конце концов, первые программисты имели дело с аппаратными стеками и всем остальным? Не очень хорошо, держу пари.

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

Я не думаю, что это это новая вещь; Я уверен, что другие языки и архитектуры тоже прошли через это. Как же, в конце концов, первые программисты имели дело с аппаратными стеками и всем остальным? Не очень хорошо, держу пари.

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

Я не думаю, что это это новая вещь; Я уверен, что другие языки и архитектуры тоже прошли через это. Как же, в конце концов, первые программисты имели дело с аппаратными стеками и всем остальным? Не очень хорошо, держу пари.

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

Я не знаю » не думаю, что это что-то новое; Я уверен, что другие языки и архитектуры тоже прошли через это. Как же, в конце концов, первые программисты имели дело с аппаратными стеками и всем остальным? Не очень хорошо, держу пари.

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

Я не знаю » не думаю, что это что-то новое; Я уверен, что другие языки и архитектуры тоже прошли через это. Как же, в конце концов, первые программисты имели дело с аппаратными стеками и всем остальным? Не очень хорошо, держу пари.

I think that Jan-Willem Maessan's pH compiler is/was strict. The next closest is Robert Ennal's speculative evaluation fork for ghc 5. The spec_eval fork is not strict, but instead optimistically evaluates. I don't know if either of those are still current/usable/etc.

Использование nfdata и rnf повсюду не является решением, поскольку это означает многократное обращение к большим структурам, которые уже были оценены.

Вводная глава докторской диссертации Бена Липпмайера (о DDC) является лучшей критикой Хаскеля, которую я видел - в ней обсуждаются вопросы лени, деструктивного обновления, трансформации монад и т.д. В DDC есть лень, но вы должны запросить ее явно, и она считается эффектом, который отслеживается и управляется системой типов и эффектов DDC.