Haskell: -fglasgow-exts следует избегать кода, который требует этого?

Question

Я новичок в Haskell, и я начал видеть ошибки, подобные:

Illegal parallel list comprehension: use -fglasgow-exts

Я работаю в ghci и ghc, но только из-за того, что это был первый, который я нашел при поиске.

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

Конкретный пример -

fibs = 0 : 1 : [ a + b | a <- fibs | b <- tail fibs ]

Я предполагаю, что тот факт, что и 1013 *, и b читают из списка одновременно, вызывает проблемы ...? Итак, если расширения Глазго являются единственным средством поддержки этой конструкции, то более распространенным является создание списка другим способом или просто предположить, что расширения будут доступны?

Заранее спасибо за любой вклад.

[EDIT] Извините, если это было не совсем понятно, но мой вопрос в том, считается ли включение расширений Глазго (или любых других) плохой практикой. Приведенный выше пример был просто для иллюстрации типа ошибки, которая вызвала этот вопрос.

Answer 1

Вместо запроса всех расширений GHC укажите, какие из них используются, используя механизм прагмы LANGUAGE:

{-# LANGUAGE ParallelListComp #-}
xy = [ x+y | x <- [1, 2, 3, 4] | y <- [5, 6, 7, 8] ]

Я предполагаю, что оба a и b читают из списка на В то же время вызывает проблемы здесь ...? Так, если расширения Глазго являются единственными средства для поддержки этой конструкции это чаще генерировать список иначе или просто предположим, что расширения будут доступны?

Допускается параллельная итерация по одному и тому же списку. Проблема в том, что параллельные понимания не определены в стандарте Haskell 98. Их можно легко смоделировать с помощью zip:

xy = [x+y | (x,y) <- zip [1, 2, 3, 4] [5, 6, 7, 8]]

Сами расширения неплохие - большая часть стандартной библиотеки использует расширения того или иного рода. Многие рассматриваются для включения в Haskell ', следующую итерацию стандарта Haskell. Некоторые расширения, такие как GADT, обычно используются в пользовательских библиотеках. Другие, такие как шаблоны или несвязные экземпляры, вероятно, не очень хорошая идея, если вы действительно не знаете, что делаете.

Любое расширение, указанное на вики-странице HaskellExtensions с поддержкой двух или более компиляторов, вероятно, безопасно для использования.

Answer 2

Использование расширений в порядке. Отметьте их специально с помощью -XFoo или LANGUAGE FOO. Какие расширения вы решите использовать, зависит от вас, вы можете придерживаться тех расширений, которые перечислены для включения в Haskell Prime.

Answer 3

GHC определенно распространен - ​​я думаю, что это наиболее используемый компилятор Haskell, так что, вероятно, он не вызовет особых проблем Вы всегда должны пытаться писать совместимый со стандартами код, хотя, может быть, не для личных проектов, а для OSS или рабочих, безусловно.

Что-нибудь может случиться, верно? Так может внезапное изменение в компиляторе на полпути через ваш проект.

В OSS разные люди используют разные компиляторы - например, HUGS также довольно распространен.

Answer 4

То, что вы хотите:

fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

Это потому, что списочные выражения не работают с самоссылочными списками. Кроме того, хотя GHC более популярен, HUGS обычно выдает более четкие сообщения об ошибках.

Answer 5

Я собирался предложить использовать «,» вместо «|», но потом я узнал, что это делает нечто иное, чем я ожидал.

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

Некоторые расширения не оказывают негативного влияния на читаемость (результирующий код очевиден), например MultiParamTypeClasses, FlexibleContexts, FlexibleInstances.

Другие требуют от читателя знакомства с новым синтаксисом и понимания того, что означает этот синтаксис. Примерами могут быть ParallelListComp, TypeFamilies, FunctionalDependencies. В этом случае я бы рекомендовал избегать этих расширений, если они не приносят пользы. В этом случае вы можете просто использовать zip, как предположил Джон Милликин, или изменить код, как предложено неизвестным.

+ 1 предложение Дона по использованию тех, которые планируется включить в Haskell Prime .

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