In theory, Haskell modules should contain all information necessary to interpret/compile them properly. In practice, many modules don't because their authors are flagging required language extensions in build systems rather than in module sources. This practice causes problems because then it becomes much hard to move modules between packages or to use a particular module outside of a particular build system context. I experience this problem when I use SearchPath to build HAppS applications. For example, $ sp runhaskell MyModule.hs will recursively download imported modules into a local directory and then run: $ runhaskell -i.haskell-cache MyModule.hs If all the imported modules contain all the right flags in their source then MyModule.main will just run (no need for manual recursion of through a cabal package depency tree!). If some of the imported modules do not include the correct flags, then an error message will result and I am then forced to do: $ sp runhaskell MyModule.hs -cpp -fglasgow-exts -etc And this is bad because (1) some of the modules may not want a particular extension turned on and (2) it is annoying to the user to have to guess at required extensions until they are all added on the command line. Problem (1) is probably small as evidenced by cabals use of global extensions without much complaint. Problem (2) is bigger. Most other modern languages e.g. Java, Python, Perl, Ruby, etc. don't rely on the compiler/interpreter command line options to designate language extensions. Neither should haskell. The correct answer, I believe, is to require that module authors put flags in the module themselves where they belong. At very least it should be considred bad style not to have them in your code and really what would make more sense is for compiler writers to disable command line flags that specify lanaguge-extensions. -Alex- PS Until this is resolved, though it is a hack, I will probably have searchpath automatically add all ghc language extension flags to the command line if the user is using ghc, runghc, or ghci i.e.: "-cpp -fth -fglasgow-exts -fallow-undecidable-instances -fallow-incoherent-instances -fallow-overlapping-instances" Another solution would be to have searchpath map files also carry cabal file URLs and get the flag from there, but some people still use makefiles or other randomness and I would like to make Searchpath work with java, perl,python, and ruby without much change.