Конвенция для определения расширений в кабальном проекте
Для любого файла.hs вы можете указать следующие языковые расширения:
{-# LANGUAGE Foo, Bar, Baz #-}
Кабализированный проект также может указывать языковые расширения для каждого проекта в файле.cabal:
extensions: Foo, Bar, Baz
Что из этого считается "лучшей практикой"? Должны ли все используемые расширения быть перечислены в файле.cabal как форма документирования, с каким компилятором совместим ваш пакет? Или все расширения должны быть отмечены отдельно для каждого файла, чтобы было ясно, какие файлы зависят от каких расширений? Как насчет широко документирования в обоих местах? Или лучшая практика где-то посередине?
2 ответа
Это зависит от того, сколько они используют. Если вы используете расширение в каждом модуле вашего проекта, вы можете поместить его в свой файл cabal; например, если вы везде используете директивы препроцессора C, имеет смысл CPP в вашем extensions поле, а не перечислять его снова и снова, и если у вас есть много сложных объявлений экземпляров в ваших модулях, было бы разумно поместить FlexibleInstances и там тоже.
Но "опасные" расширения (вроде UndecidableInstances), а расширения, используемые только в нескольких местах, должны идти вверху вашего файла: первый для документации (то есть, "вот вам, драконы"), второй для документации и для сохранения эффектов расширений изолированными, так что вы не Случайно использовать эффекты расширения, которые вы не собирались использовать в другом модуле.
В общем, я бы допустил ошибку, поместив их в начало файла и используя только extensions поле при указании расширения снова и снова становится раздражающим.
Хорошо, и вопрос, и ответ очень старые. Поэтому я поставил некоторые обновления о состоянии расширения. Если вы используете некоторые безопасные языковые расширения (например, -XRecordWildCards, -XDeriveDataTypeable, -XTypeVariables) во многих модулях или нахожу надоело ставить {-# LANGUAGE ... #-} Прагма в верхней части уровня (поскольку вы можете не знать о некоторых средах разработки или инструментах, которые позволяют автоматически размещать языковые прагмы), тогда вам следует использовать default-extensions: поле. Обратите внимание, есть также other-extensions: поле, которое, на мой взгляд, очень запутанно и никогда не должно использоваться. Смотрите примеры здесь.