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.
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. 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). If you could specify overlapping on a per-instance basis, then that would be a way around the problem. Cheers, Simon
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.
Further to my last point, what if the top level module is Main... ghci Main.hs and that includes a main function, and pragmas, so that main runs when ghci is finished loading (automatically). If main runs automatically then the context of ghci must be the Main module, so why would the options pragmas not be in effect? for example: ghc -o test Main.hs needs no flags and I can then run test with no flags (./test). But: ghci Main.hs Now all of a sudden you are telling me I need to provide command line flags to get it to run (in the interpreter) but I do not need to if I use the compiler... (remember this worked fine in 6.3 and 6.3 included the new lazy instance overlap detection) This seems very inconsistant to me... I really like the ability to put any flags code might need into the source using the OPTIONS pragmas... but it seems to undermine the usefulness of this if ghci ignores the flags. Keean
participants (2)
-
Keean Schupke -
Simon Marlow