GHCi won't load compiled object files outside of a package

[lpsmith]

$ ghci fib.hs
GHCi, version 7.0.3: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling Fib              ( fib.hs, interpreted )
Ok, modules loaded: Fib.
> fib 26
121393
(0.23 secs, 69689600 bytes)
> :q
Leaving GHCi.


$ ghc fib.hs
[1 of 1] Compiling Fib              ( fib.hs, fib.o )


$ ghci fib.hs
GHCi, version 7.0.3: http://www.haskell.org/ghc/  :? for help
Ok, modules loaded: Fib.
> fib 26
121393
(0.04 secs, 37823328 bytes)

$ ghci fib.hs
GHCi, version 7.4.0.20120111: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling Fib              ( fib.hs, interpreted )
Ok, modules loaded: Fib.
> fib 26
121393
(0.25 secs, 71126112 bytes)
> :q
Leaving GHCi.


$ ghc fib.hs
[1 of 1] Compiling Fib              ( fib.hs, fib.o )


$ ghci fib.hs
GHCi, version 7.4.0.20120111: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling Fib              ( fib.hs, interpreted )
Ok, modules loaded: Fib.
> fib 26
121393
(0.24 secs, 69966016 bytes)

[simonmar]

I can't reproduce this. Are you sure that ghc is referring to GHC 7.4.20120111?

[lpsmith]

After a bit more investigation, the problem is related to my ghci.conf:

:set +s
-- :set -XScopedTypeVariables
:set prompt "> "
-- :set -XOverloadedStrings
-- :a ~/.ghc/env.hs

It loads a compiled module with the abouve ghci.conf, but if any one of the commented lines are uncommented (as they normally are) then ghci will interpret fib.hs instead of loading the compiled module. ~/.ghc/env.hs is

import Data.ByteString.Char8()
import Data.ByteString.Lazy.Char8()
import Data.Text()
import Data.Text.Lazy()

To import the IsString? instances into the interactive environment. (I realize this need not be a separate file anymore; but it was a workaround for an older version of GHC.)

Now, if I compile with the exact same language extensions as specified in my ghci.conf, then it will load the compiled module. But any difference seems to lead to interpretation.

[simonmar]

This is a feature, not a bug! GHC has to recompile the source file, just in case the different language extensions have any effect. See #437.

[lpsmith]

Well, I disagree that all of the language flags need to be included here; for example, ViewPatterns. Are there any programs that compile without the ViewPatterns flag that behave any differently with it enabled?

This is a step forward in terms of usability when it comes to the compiler, but it seems a step backwards when it comes to ghci. Especially the OverloadedStrings? issue.

[simonmar]

Admittedly we didn't do a full audit of the flags to see where we could be more relaxed, but apart from the fact that it would be time-consuming and error prone to do that, the current implementation can't handle the requirement that *adding* ViewPatterns is (probably) safe but *removing* it is not. That's because we just take a hash of the flags and store that in the interface file.

I understand the problem - having some extensions on in GHCi by default is quite handy, but you don't want that to cause recompilation of files that you've already compiled. I think the right fix for that would be to separate the flags that are in use at the GHCi prompt from those that are used when loading source files: see #3217. I'm going to bump the priority of that ticket, now that dealing with it is more pressing.

[lpsmith]

Ok, that sounds like a good solution. It doesn' make sense to me at the moment why the :a ~/ghc/env.hs causes recompilation, but I note that I can move the imports into the ghci.conf to get around that, and that I really don't use the older versions of ghc (6.10?) that was intended for much anymore.