GHC 6.4 release candidates available

Keean Schupke k.schupke at imperial.ac.uk
Fri Mar 4 10:27:27 EST 2005


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.



More information about the Glasgow-haskell-users mailing list