[Haskell] -compiler-options vs {#-LANGUAGE Flags-#}

S. Alexander Jacobson alex at alexjacobson.com
Fri Mar 23 17:16:26 EDT 2007

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.


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.

More information about the Haskell mailing list