-compiler-options vs {#-LANGUAGE Flags-#}
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.
S. Alexander Jacobson on 2007-03-23 17:16:26 -0400:
The correct answer, I believe, is to require that module authors put flags in the module themselves where they belong.
Does the OPTIONS_GHC pragma solve your issue? http://www.haskell.org/ghc/docs/latest/html/users_guide/using-ghc.html#sourc...
I think the LANGUAGE pragma is better than the OPTIONS_GHC pragma but I am relatively indifferent on that issue. My only point is that module authors should put this information in the module source rather than in the build system. -Alex- On Fri, 23 Mar 2007, Alec Berryman wrote:
S. Alexander Jacobson on 2007-03-23 17:16:26 -0400:
The correct answer, I believe, is to require that module authors put flags in the module themselves where they belong.
Does the OPTIONS_GHC pragma solve your issue?
http://www.haskell.org/ghc/docs/latest/html/users_guide/using-ghc.html#sourc... _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 S. Alexander Jacobson wrote:
I think the LANGUAGE pragma is better than the OPTIONS_GHC pragma but I am relatively indifferent on that issue. My only point is that module authors should put this information in the module source rather than in the build system.
I think the LANGUAGE pragma is much better than OPTIONS_GHC, for several reasons. * It's compiler independent. * It's clear that you're only adding extensions, not any random compiler flag. * It plays nicely with Ian's proposal on http://article.gmane.org/gmane.comp.lang.haskell.cabal.devel/464 Alexander, I've added LANGUAGE pragmas to binary, let me know how it works out for you. Cheers, Lennart Kolmodin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGBRcW4txYG4KUCuERAq2qAJ9Cd//bRv53Q+pr3Sab5r7JE4CSIgCgnAzG FgLR4dBZkCTmecN8R9IrpYI= =iqeA -----END PGP SIGNATURE-----
On Sat, Mar 24, 2007 at 01:18:30PM +0100, Lennart Kolmodin wrote:
I think the LANGUAGE pragma is much better than OPTIONS_GHC, for several reasons.
* It's compiler independent. * It's clear that you're only adding extensions, not any random compiler flag. * It plays nicely with Ian's proposal on http://article.gmane.org/gmane.comp.lang.haskell.cabal.devel/464
A very big problem with the pragma as it relates to Distribution.Extension is that it is unextensable. The definition in Distribution.Extension really should be
newtype Extension = Extension String
and the flags transformation should be something like
extensionsToFlags :: Compiler -> [Extension] -> ([Extension],[Opt]) extensionsToFlags = ...
enumerating the compilers or allowed extensions in the API is very limiting as well as complicating to the code. This is a major problem with Distribution.* in general actually that needs to be cleaned up at some point. (Distribution2.* ?) hrm.. John -- John Meacham - ⑆repetae.net⑆john⑈
On Thu, Apr 05, 2007 at 10:42:09AM -0700, John Meacham wrote:
On Sat, Mar 24, 2007 at 01:18:30PM +0100, Lennart Kolmodin wrote:
I think the LANGUAGE pragma is much better than OPTIONS_GHC, for several reasons.
* It's compiler independent. * It's clear that you're only adding extensions, not any random compiler flag. * It plays nicely with Ian's proposal on http://article.gmane.org/gmane.comp.lang.haskell.cabal.devel/464
A very big problem with the pragma as it relates to Distribution.Extension is that it is unextensable. The definition in Distribution.Extension really should be
newtype Extension = Extension String
and the flags transformation should be something like
extensionsToFlags :: Compiler -> [Extension] -> ([Extension],[Opt]) extensionsToFlags = ...
enumerating the compilers or allowed extensions in the API is very limiting as well as complicating to the code.
This is a major problem with Distribution.* in general actually that needs to be cleaned up at some point. (Distribution2.* ?) hrm..
It would be a Very Good Idea to list the "valid" values in the haddocks, to ensure consistency. We can handle assignment with a "Find a missing extension? Invent a name and patch this list!" clause. Stefan
On Thu, Apr 05, 2007 at 10:53:31AM -0700, Stefan O'Rear wrote:
On Thu, Apr 05, 2007 at 10:42:09AM -0700, John Meacham wrote:
On Sat, Mar 24, 2007 at 01:18:30PM +0100, Lennart Kolmodin wrote:
I think the LANGUAGE pragma is much better than OPTIONS_GHC, for several reasons.
* It's compiler independent. * It's clear that you're only adding extensions, not any random compiler flag. * It plays nicely with Ian's proposal on http://article.gmane.org/gmane.comp.lang.haskell.cabal.devel/464
A very big problem with the pragma as it relates to Distribution.Extension is that it is unextensable. The definition in Distribution.Extension really should be
newtype Extension = Extension String
and the flags transformation should be something like
extensionsToFlags :: Compiler -> [Extension] -> ([Extension],[Opt]) extensionsToFlags = ...
enumerating the compilers or allowed extensions in the API is very limiting as well as complicating to the code.
This is a major problem with Distribution.* in general actually that needs to be cleaned up at some point. (Distribution2.* ?) hrm..
It would be a Very Good Idea to list the "valid" values in the haddocks, to ensure consistency. We can handle assignment with a "Find a missing extension? Invent a name and patch this list!" clause.
oh, yes of course. I was thinking a wiki page could list valid ones and pointers to the papers/documentation describing them. and of course, we can reserve X-Foo named extensions for as yet to be standardized or experimental extensions so developers have a playground to work in as extensions evolve. John -- John Meacham - ⑆repetae.net⑆john⑈
On 05/04/07, John Meacham <john@repetae.net> wrote:
A very big problem with the pragma as it relates to Distribution.Extension is that it is unextensable.
Yet another use case for Andres Löh and Ralf Hinze's open datatypes [1]. Shame they're still lacking an implementation. [1]: http://www.informatik.uni-bonn.de/~loeh/OpenDatatypes.html -- -David House, dmhouse@gmail.com
"S. Alexander Jacobson" <alex@alexjacobson.com> wrote:
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.
I strongly support this. I think the LANGUAGE pragma of GHC-6.6 is a step in the right direction. It is unfortunate that GHC still proposes to use -fglasgow-exts whenever it suspects use of extensions; it would be better to propose the appropriate extension for the LANGUAGE pragma. (By the way, why is there no extension for GADTs? My impression is that there is a number of other extensions, each of which is sufficient individually to enable GADTs. Some more documentation in Language.Haskell.Extension would also be useful... ) Wolfram
participants (7)
-
Alec Berryman -
David House -
John Meacham -
kahl＠cas.mcmaster.ca -
Lennart Kolmodin -
S. Alexander Jacobson -
Stefan O'Rear