[Haskell-cafe] Why Haskell?

[Matthew Bromberg]

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
>
>