Конвенция для определения расширений в кабальном проекте - PullRequest
7 голосов
/ 03 марта 2012

Для любого файла .hs вы можете указать языковые расширения, на которые вы полагаетесь, например:

{-# LANGUAGE Foo, Bar, Baz #-}

В кабальном проекте также можно указать языковые расширения для каждого проекта в файле .cabal:

extensions: Foo, Bar, Baz

Что из этого считается «наилучшей практикой»?Должны ли все используемые расширения быть перечислены в файле .cabal в качестве формы документирования, с каким компилятором совместим ваш пакет?Или все расширения должны быть отмечены отдельно для каждого файла, чтобы было ясно, какие файлы зависят от каких расширений?Как насчет широко документирования в обоих местах?Или лучшая практика где-то посередине?

Ответы [ 2 ]

7 голосов
/ 03 марта 2012

Это зависит от того, сколько они используются.Если вы используете расширение в каждом модуле вашего проекта, вы можете поместить его в свой файл cabal;например, если вы везде используете директивы препроцессора C, имеет смысл помещать CPP в поле extensions, а не перечислять его снова и снова, и если у вас много сложных объявлений экземпляров в ваших модулях, это можетразумно поставить туда также FlexibleInstances.

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

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

0 голосов
/ 03 июня 2017

Хорошо, и вопрос, и ответ очень старые.Поэтому я поставил некоторые обновления о состоянии расширения.Если вы используете некоторые безобидные языковые расширения (например, -XRecordWildCards, -XDeriveDataTypeable, -XTypeVariables) во многих модулях или вам неудобно помещать прагму {-# LANGUAGE ... #-} в начало уровня (потому что вы можете не знать о некоторыхIDE или инструменты, которые позволяют автоматически добавлять языковые прагмы), тогда вам следует использовать поле default-extensions:.Обратите внимание, есть также поле other-extensions:, которое, на мой взгляд, очень запутанно и никогда не должно использоваться.См. примеры здесь .

...