Нелинзовая ветка GHC

Question

Я слышал, что есть ветка GHC, которая по умолчанию компилируется по строгом коде, а ленту можно включить аннотацией. (IIRC, он сказал, что финансовая компания развивает отрасль и использует ее для производственного кода.) Это правда? Я не могу найти его.

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

Все, что я нахожу в строгом Haskell, - это такие вещи, как $! и rnf. Хотя я считаю, что ленивая оценка очень элегантная, я хотел бы разработать программу в Haskell, где я хочу избежать утечек пространства и хотел бы иметь предсказуемую производительность.

Отказ от ответственности: Я не делаю случай строгости, я просто хотел бы взглянуть на строгий Haskell или что-то в этом роде.

Answer 1

Вы ищете Disciple.

Таким образом, в Haskell можно различать два вида лень. Существует ленивый ввод-вывод, который является мерзостью и решается библиотеками iteratee (бесстыдная плагин: включая мою библиотеку pipes). Тогда есть леность в чистых вычислениях, которые по-прежнему открыты для обсуждения, но я попытаюсь суммировать основные преимущества лени, так как вы уже знакомы с недостатком:

Лень является более эффективным

A простой пример:

any = foldr (||) False 

any находит, если какое-либо значение в списке True. Это оценивает только элементы до первого True, поэтому не имеет значения, слишком ли длинный список.

Laziness вычисляет столько, сколько нужно, что означает, что если вы объедините две ленивые вычисления, это может фактически улучшить временную сложность полученных вычислений. This Stack Overflow comment дает еще один хороший пример этого.

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

Лень по своей природе более компонуемы

Это хорошо известны людям, которые запрограммированы в строгих, так и функциональных языках, но я на самом деле невольно продемонстрировал ограниченное доказательство этого во время работы на pipes библиотеки, где ленивая версия - единственная версия, которая разрешает экземпляр Category. Трубы действительно работают в любой монаде, включая чистую монаду Identity, поэтому мои доказательства переводят и на чистый код.

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

Answer 2

Если я правильно понимаю, строгий Haskell не может иметь монадического ввода-вывода, как мы его знаем.Идея в Haskell заключается в том, что весь код Haskell является чистым (который включает в себя действия IO, которые работают как государственная монада), а «main» дает значение типа IO() для среды выполнения, которая затем многократно воздействует на оператор последовательности >> = ,

Для контрапункта к сообщению Tekmo вы можете посмотреть блог Роберта Харпера, * http://existentialtype.wordpress.com/2011/04/24/the-real-point-of-laziness/ и связанные с ним. Это происходит в обоих направлениях.

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

Классическая пропагандистская статья для лени - это статья Хьюза «Почему вопросы функционального программирования», которую вы должны легко найти.

Answer 3

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

Функция применения в Haskell не является строгой; то есть аргумент функции оценивается только тогда, когда это необходимо.

~ Haskell Report 2010 > Predefined Types and Classes # Strict Evaluation

Это немного вводит в заблуждение, однако. Реализации могут оценивать аргументы функции до их необходимости, но только в ограниченной степени. Вы должны сохранить нестрогую семантику: поэтому, если выражение для аргумента приводит к бесконечному циклу, и этот аргумент не используется, то вызов функции с этим аргументом не должен содержать бесконечный цикл.

Итак, вы : разрешено реализовать Haskell таким образом, который не является полностью «ленивым», но тем не менее он не может быть «строгим». Это кажется противоречием с первого взгляда, но это не так. Несколько связанных тем, которые вы, возможно, захотите проверить:

• Eager Haskell, реализация языка программирования Haskell, который по умолчанию использует высокую оценку. Я считаю, что это то, о чем вы думали (хотя это не филиал GHC).
• Speculative Execution и спекулятивный параллелизм (см., Например, пакет speculation).
• Optimistic Evaluation, статья SPJ об ускорении GHC с оптимизацией строгости.

Answer 4

Похоже, вы слышали о Роберте Энналсе «PhD thesis on speculative evaluation с GHC». Он создал вилку GHC под названием «spec_eval», где была сделана спекулятивная оценка. Поскольку Haskell является нестрогим, а не явно ленивым, spec_eval был строго до того момента, когда он фактически изменил ситуацию. Хотя во всех случаях он был быстрее, он требовал больших изменений в GHC и никогда не сливался.

Этот вопрос имеет вид been answered before на этом сайте.