ghci reports functions not in scope after loading a .hs, if there is a .o present

[guest]

I wanted to debug some code, so I fired up ghci and had this experience:

> :l foo.hs
...
> my_func 1 2 3

<interactive>:1:0: Not in scope: `my_func'

Apparently, this was because I had previously compiled the code, and ghci noticed the .o file and loaded that instead of the source file. As a result, anything not explicitly exported was not visible.

Once I quit, removed the .o, restarted ghci, and reloaded the file; it worked as I was expecting.

It seems to me that ":load foo.hs" should load foo.hs, with no funny business. Anything else is likely not doing what the user expects. I'd be fine with ":l foo" loading a compiled version if available, and I'm fine with imports from the code I'm loading a compiled version. But, when I explicitly say to load one file, and some other file is loaded instead; that seems like bad behavior.

[simonmar]

Personally I don't consider this a bug: the behaviour is clearly documented, and GHC tells you that it is loading the .o file in the output from :load. The fact that :load foo is just shorthand for :load foo.hs is a good thing, IMO.

If you want to force compilation, then :!touch foo.hs works fine. Given this, the argument that we should provide special support seems weak, to me. You can even define a macro, e.g.

 :def interpret (\str -> return (":!touch " ++ str ++  "\n:load " ++ str))

I'll leave this open as a feature request in case others want to comment. If there's a concensus for a change, we can turn it into a task.

[igloo]

#1439 is another vote for some sort of change.

[Isaac Dupree]

On a related note, it would be nice if there was a flag to give to ghc (not i) to produce .o/.hi files that contain enough internal information to have ghci load them and be able to be "inside" the module. When using that and compiling separately, ghci would load quickly and nevertheless work (mostly?) as expected... (I have no idea how hard this would be nor if something like this already exists)

[Isaac Dupree]

Actually, that could be positively useful considering when ghci needs things to be compiled first <http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-faq.html> ... including -O, though "exporting" everything in a module like this would probably have some impact on optimizations? Separately, it would be nice to avoid modules that depend on this one from having to be recompiled more often, since _they_ only depend on the external module interface...

[igloo]

Also reported as #1682.

[simonmar]

Bumping this as it is an oft-reported source of confusion. We'll do something for 6.10.

[simonmar]

Fixed:

Wed Jul  9 12:08:30 BST 2008  Simon Marlow <marlowsd@gmail.com>
  * #1205: ':load foo.hs' in GHCi always compiles to bytecode
  
  So now
  
    :load foo.hs       loads bytecode for foo.hs, even if foo.o exists
    :load foo          is just shorthand for :load foo.hs
    :load M            loads a module M, as object code if possible
                       (no change here)
  
    :set -fobject-code
    :load foo.hs       loads foo.hs as object code; an existing foo.o
                       can be used.
    
  This turned out to be very straightforward: when building the
  ModSummary for a file (summariseFile) we just ignore the object file
  unless -fobject-code is on.

[simonmar]

We plan to change the way this works again: see #2542.