Convención para especificar las extensiones en el proyecto cabalized

Question

Para cualquier archivo .hs, puede especificar las extensiones de lenguaje que se basan en este modo:

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

Un proyecto cabalized también puede especificar extensiones de lenguaje en función de cada proyecto en el archivo .cabal:

extensions: Foo, Bar, Baz 

¿Cuál de estas opciones se considera una "práctica recomendada"? ¿Deben todas las extensiones utilizadas enumerarse en el archivo .cabal, como una forma de documentar con qué compiladores es compatible su paquete? ¿O deberían anotarse todas las extensiones por archivo, para dejar en claro qué archivos dependen de qué extensiones? ¿Qué hay de documentar ampliamente en ambos lugares? ¿O es mejor práctica en algún lugar intermedio?

Answer 1

Depende de cuánto se usan. Si usa una extensión en cada módulo de su proyecto, puede ponerla en su archivo cabal; por ejemplo, si usa directivas de preprocesador C en todas partes, tiene sentido poner CPP en su campo extensions en lugar de enumerarlo una y otra vez, y si tiene muchas declaraciones de instancia complicadas en sus módulos, podría ser razonable poner FlexibleInstances allí también.

Pero las extensiones "peligrosas" (como UndecidableInstances) y las extensiones que solo se usan en algunos lugares deben ir en la parte superior del archivo: la primera para documentación (es decir, "aquí dragones"), esta última para documentación y para mantener aislados los efectos de las extensiones, para que no use accidentalmente los efectos de una extensión donde no tenía intención de hacerlo en otro módulo.

En general, me gustaría equivocarme al ponerlos en la parte superior del archivo, y solo al usar el campo extensions al especificar una extensión una y otra vez se vuelve molesto.

Answer 2

Ok, tanto la pregunta como la respuesta son muy antiguas. Así que puse una actualización sobre el estado de la extensión. Si utiliza extensiones de lenguaje inofensivas (como -XRecordWildCards, -XDeriveDataTypeable, -XTypeVariables) en muchos módulos o encuentra molesto poner {-# LANGUAGE ... #-} pragma en la parte superior del nivel (porque es posible que no conozca algunos IDE o herramientas que le permiten pragmas de idioma automáticamente) entonces debería usar el campo default-extensions:. Tenga en cuenta que también existe el campo other-extensions: que, en mi opinión, es muy confuso y nunca debe utilizarse. Ver examples here.