ghci 7.4.1 no longer loading .o files?

[Simon Marlow]

On 21/02/2012 04:33, Evan Laforge wrote:
> On Mon, Feb 20, 2012 at 1:14 AM, Eugene Crosser<crosser at average.org>  wrote:
>> On 02/20/2012 10:46 AM, Evan Laforge wrote:
>>> Is there something that changed in 7.4.1 that would cause it to decide
>>> to interpret .hs files instead of loading their .o files?  E.g.:
>>
>> I don't *know* but could this have anything to do with this?
>>
>> http://hackage.haskell.org/trac/ghc/ticket/5878
>
> Indeed it was, I initially thought it wasn't because I wasn't using
> flags for either, but then I remember ghci also picks up flags from
> ~/.ghci.  Turns out I was using -fno-monomorphism-restriction because
> that's convenient for ghci, but not compiling with that.
>
> I guess in the case where an extension changes the meaning of existing
> code it should be included in the fingerprint and make the .o not
> load.  But my impression is that most ExtensionFlags let compile code
> that wouldn't compile without the flag.  So shouldn't it be safe to
> exclude them from the fingerprint?
>
> Either way, it's a bit confusing when .ghci is slipping in flags that
> are handy for testing, because there's nothing that tells you *why*
> ghci won't load a particular .o file.

I just committed a fix for this:

http://hackage.haskell.org/trac/ghc/ticket/3217#comment:28

What do people think about getting this into 7.4.2?  Strictly speaking 
it's more than a bug fix, because it adds a new GHCi command (:seti) and 
some extra functions to the GHC API, although I believe it has no effect 
on existing usage of GHCi or the GHC API.

The docs explicitly mention -XNoMonomorphismRestriction.  The way to 
work around the problem you had is to use

   :seti -XNoMonomorphismRestriction

in your ~/.ghci, instead of :set.  One disadvantage of this is that your 
.ghci won't work with older versions of GHC. (does anyone have some 
.ghci magic for doing conditional compilation?)

Furthermore, I'm shortly going to push a patch that will add an 
indication of why modules are being recompiled.  Here's the log message:

commit 27d7d930ff8741f980245da1b895ceaa5294e257 (HEAD, refs/heads/master)
Author: Simon Marlow <marlowsd at gmail.com>
Date:   Thu Mar 1 13:55:41 2012 +0000

     In --make, give an indication of why a module is being recompiled

     e.g.

     [3 of 5] Compiling C                (C.hs, C.o)
     [4 of 5] Compiling D                (D.hs, D.o) [C changed]
     [5 of 5] Compiling E                (E.hs, E.o) [D changed]

     The main motivation for this is so that we can give the user a clue
     when something is being recompiled because the flags changed:

     [1 of 1] Compiling Test2            ( Test2.hs, Test2.o ) [flags 
changed]


Cheers,
	Simon