| 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