There can only be one top level module in ghci (there can only be one module name before the '>' prompt - that modules options should be in effect. The whole point of putting options at the top of the source file is so that the user/compiler of the code does not need to know which specific options are required. If the code specifies "overlapping instances", I don't expext to have to specify it on the command line as well. Simon Marlow wrote:
I think GHC's behaviour is right here. To use the flag settings from the source module on the command-line would be wrong: for example, when the module is compiled, its implementation (and therefore flag settings) must be hidden.
Requiring options on the command line exposes the implementation I do not expect the GHCi user to be required to know which flags to apply to get my code to run.
Also, as Simon pointed out, there might be multiple modules in scope at the prompt, so how do you resolve the flag settings if they're contradictory?
Only the flags from the top level (the one named before the prompt) would be in scope. If I type: ghci Test.hs Then I would expect the options pragma in Test.hs to be in effect.
In general, flag settings affect the current source file only. The flag settings at the GHCi prompt are those given on the command line and from :set - it's simple, no worrying about "where did that option come from? I don't want overlapping instances!".
I really don't like GHCi users needing to know what flags they must use to get code to work. There must be some way of code asserting top level options. If the options pragma cannot be used for this purpose I suggest there should be another way for code to assert top level options of ghci... this method should be in the source file so that extra options files are not required... Keean.