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

Question

Я ищу компилятор Haskell, который использует строгую оценку по умолчанию вместо ленивой оценки. Я бы просто использовал OCaml, но синтаксис Haskell намного лучше , чем синтаксис OCaml (а Haskell чист и имеет классные функции, такие как классы типов).

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

Пожалуйста, не пытайтесь убедить меня, что ленивая оценка лучше, мне действительно нужна производительность. IIRC, Саймон Пейтон Джонс даже сказал, что ленивая оценка на самом деле не нужна, она была в основном для того, чтобы помешать им сделать язык нечистым.

Answer 1

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

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

Answer 2

Если у вас есть компилятор Haskell, который использует строгую оценку, он не компилирует Haskell. Лень Нестрогость является частью спецификации Haskell!

Однако, есть альтернативы.

• DDC - это попытка создать явно ленивый вариант Haskell, который поддерживает такие вещи, как деструктивное обновление, сохраняя при этом все остальные достоинства Haskell. Есть одна проблема: компилятор в настоящее время находится только в α-стадии, хотя кажется, что он по крайней мере пригоден для использования.

• Создайте препроцессор, как это сделали другие.

• Научитесь правильно использовать Haskell. Если вы можете упростить свой тестовый пример до чего-то, что будет доступно для публичного показа, вы можете опубликовать его в списке рассылки Haskell-Café *1022*, где люди очень помогают с такими вопросами о последствиях строгость.

Answer 3

В прошлом было две попытки строго оценить Haskell:

• Ян-Виллем Мессен Жадный Хаскелл
• Роб Энналс Докторская диссертация

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

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

Answer 4

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

Answer 5

Я чувствую твою боль. Моя самая большая PITA в моем повседневном программировании имеет дело с этими! @ # $% ^ & (Пробелы в космосе.

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

Я не буду пытаться убедить вас, что ленивая оценка - лучшая вещь в мире, но в этом есть определенные плюсы. У меня есть несколько программ потоковой обработки, которые отбрасывают ленивые списки с помощью любых разнообразных комбинаторов, которые успешно работают с гигабайтами данных, используя не более 3,5 МБ памяти (из которых более 2 МБ - время выполнения GHC). И кто-то умнее, чем я, сказал мне в прошлом году, что вы, как типичный программист на Haskell, действительно удивитесь тому, насколько сильно вы зависите от ленивых вычислений.

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

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

Answer 6

Я недавно видел некоторые работы в этой области:

https://ghc.haskell.org/trac/ghc/wiki/StrictPragma

Вы можете услышать об этом немного в обновлении статуса SPJ GHC здесь:

http://youtu.be/Ex79K4lvJno?t=9m33s (Ссылка начинается с соответствующей части в 9:33)

Answer 7

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

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

Answer 8

Я думаю, что pH-компилятор Джана-Виллема Мессана * был / был строгим. Следующим наиболее близким является спекулятивный форк оценки Роберта Эннала для ghc 5. Форк spec_eval не является строгим, но вместо этого оптимистично оценивает. Я не знаю, является ли какой-то из них все еще актуальным / годным к употреблению / и т.д.

Answer 9

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

Такой компилятор не был бы компилятором Haskell. Если вы действительно хотите, вы можете добавить {-# LANGUAGE Strict #-} прагм в свои файлы. Это будет работать с GHC 8.0.2, 8.2.2 и 8.4.1, или тремя последними выпусками компилятора.

Было бы также полезно, если бы в некоторых местах был способ использовать ленивое вычисление, на случай, если я хочу что-то вроде бесконечного списка

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

(я, вероятно, никогда не буду).

Это именно то, что авторы llvm-hs думали , когда они решили использовать строгую государственную монаду, а не ленивую. Вместо этого это вызвало неожиданную ошибку в будущем. Лень и рекурсия идут рука об руку.

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

Я сомневаюсь, что это именно то, что вам нужно, когда это не повышает надежность кода на Haskell, одновременно нарушая существующий код и делая существующие ресурсы бесполезными. Если вы собираетесь писать программы именно так, просто используйте OCaml или Scala и оставьте сообщество Haskell в покое.

IIRC, Саймон Пейтон Джонс даже сказал, что ленивая оценка на самом деле не нужна, она была в основном для того, чтобы помешать им сделать язык нечистым.

Это не правда. Вы можете прочитать больше о фактической истории Haskell здесь

Answer 10

Существует также seqaid , который стремится к середине ленивого строгого спектра.

Seqaid - плагин GHC, обеспечивающий неинвазивное автоматическое инструментарий проектов на Haskell для контроля динамической строгости (и параллелизма). Это скоро будет включать оптимизацию для автоматического устранения утечек в космосе с использованием минимальной строгости.