Convention for specifying extensions in cabalized project

Question

For any .hs file, you can specify the language extensions you rely on like so:

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

A cabalized project can also specify language extensions on a per-project basis in the .cabal file:

extensions: Foo, Bar, Baz

Which of these is considered "best practice"? Should all extensions used be listed in the .cabal file, as a form of documenting which compilers your package is compatible with? Or should all extensions be noted on a per-file basis, for the sake of making clear which files depend on which extensions? What about extensively documenting in both places? Or is best practice somewhere in-between?

Foin

Answer 1

It depends on how much they're used. If you use an extension in every module in your project, you might want to put it in your cabal file; for instance, if you use C preprocessor directives everywhere, it only makes sense to put CPP in your extensions field rather than listing it over and over, and if you have a lot of complicated instance declarations in your modules, it could be reasonable to put FlexibleInstances in there, too.

But "dangerous" extensions (like UndecidableInstances), and extensions only used in a few places, should go at the top of your file: the former for documentation (i.e. "here be dragons"), the latter for documentation and to keep the effects of extensions isolated, so you don't accidentally use an extension's effects where you didn't intend to in another module.

In general, I would err on the side of putting them at the top of the file, and only using the extensions field when specifying an extension over and over again gets annoying.

Brasca

So would it be fair to conclude from what you've said that the "extensions" section of a .cabal file isn't typically taken as a stand-alone manifest of which compilers can compile a given package? – Foin

@DanBurton: Yeah, I wouldn't interpret it that way at all; it wouldn't be a useful indicator for a program processing the Cabal file, because nothing stops you using LANGUAGE pragmas anyway, and for documentation it's more helpful to list things like that in the documentation than to put them in the Cabal file, which is essentially part of the code. – Brasca

Answer 2

Ok, both question and answer are very old. So I put some update on the state of extension'ness. If you using some harmless language extensions (like -XRecordWildCards, -XDeriveDataTypeable, -XTypeVariables) in a lot of modules or find it annoying to put {-# LANGUAGE ... #-} pragma at the top of level (because you may not be aware of some IDE's or tools that allow you to put language pragmas automatically) then you should use default-extensions: field. Notice, there's also other-extensions: field which is very confusing in my opinion and should never be used. See examples here.

Roughdry