GHC 6.4 release candidates available

[Keean Schupke]

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.