| 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