[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.
-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.
More information about the Haskell
mailing list