Well now that I understand how it works, I'm perfectly happy with the current functionality. As long as I put all my FFI imports into one module and compile that, then I can load the other modules into GHCi at will during development and testing. I was going to do some FFI imports into another module but will forgo that. I did run into an amusing problem where my matrices were not being updated after a :reload operation (or was it a :load?) and a re-evalution of main in GHCi. I view the matrices as constant globals, and therefore do an unsafePerformIO to get their indices. Another evaluation of main left the indices unchanged pointing to the old matrices. At least that what appears to have happen. I should probably take a closer look when I have a second. Simon Peyton-Jones wrote:
| I think I understand my issue now with this (other than the anomaly of | the above example). I've been using the make option with ghc to compile | all the dependent sources, creating binaries for all of them. Those | binaries can be loaded into GHCi, but if you do so it will not make the | imports available to you for use. Thus my main.hs has the header | import Matrix | import Parsefile | import Array | import NetPrams | import System.IO.Unsafe | | ..... | | If main.hs has not been brought up to date, I can load main.hs into the | interpreter and the functions defined in Matrix for example will be in | scope and usable. If on the other hand I've just run ghc on main, I can | load main.hs in, but the functions in Matrix will not be available. | Perhaps the solution is to create a script file that loads all the | modules in and adds them to the current scope.
The GHC user manual discusses this point:
http://www.haskell.org/ghc/docs/latest/html/users_guide/ch03s04.html#ghc i-scope
When you *compile* a module, GHC does a whole lot of inlining, and functions that are exported may not even exist any more. That's why you can't necessarily see the full top-level scope of a compiled module (the :m *M form described in the manual). If you *interpret* a module, GHC is careful never to discard any top-level definition, so that you can see the full top-level scope, just as you wrote it.
Maybe there should be a way to tell GHC to retain top level defns even when compiling; but currently the story is that you must interpret the .hs files if you want to see the top level defns.
Simon