Simon Marlow wrote:
On 04 March 2005 12:58, Keean Schupke wrote:
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.
No, you can have multiple top-level module scopes in effect. See the GHCi documentation.
But I can also have just one top level module ...
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.
Why not? You're providing a library which exports some instances. If overlapping instance resolution is required to resolve overloading in code that uses the library, I want to know about it, and I don't want the compiler to turn on overlapping instance resolution behind my back.
But what if it is an application and not a library... you definitely do not wantr to have to explain in the user manual that ghci needs to be started with: ghci -fglasgow-exts -fallow-overlapping-instances ... Further more it is the _importing_ module that needs to have overlapping instances defined, therefore there is absolutely no chance of them being turned on behind your back.
Importing a library should *not* affect how the code that imports it is compiled, except in the ways you expect (bringing names and instances into scope).
It would not... All I am saying is if the top level module in GHCi (the one named in the prompt) has OPTIONS pagmas these should be in effect.
If you could specify overlapping on a per-instance basis, then that would be a way around the problem.
This worked in all GHCi before 6.4 - so something has broken the (in mu opinion) correct behavior. Was this a deliberate decision - or has something just changed without anyone realising? Keean.