Подтвердить что ты не робот

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 5

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

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

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

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

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

Ответ 6

Я думаю, что Jan-Willem Maessan компилятор pH был/был строгим. Следующим ближайшим является спекулятивная критическая оценка Роберта Эннала для ghc 5. Вилка spec_eval не является строгой, но оптимистически оценивается. Я не знаю, все ли по-прежнему текущие/используемые/и т.д.

Ответ 7

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

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

Ответ 9

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

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

Ответ 10

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