ghc vs ghci: why can't ghci do everything ghc can do?

[Simon Marlow]

Claus Reinke wrote:
> btw, it would still be nice to have ghci limitations (vs ghc) summarized 
> on a wiki page. i've seen fragments here and
> there, but no complete list answering my questions.
> 
>>   :set -fobject-code
>>   :reload
> 
> ah, thanks! i had forgotten about that one. it doesn't solve my main 
> problem but i guess what i'm asking for could be rephrased as:
> an _implied_ {-# OPTIONS_GHC -fobject-code #-}
> for only those modules which ghci can't handle itself.
> 
>>   :load M.hs N.hs
> 
> i also liked the suggestion that ':m *M' should always
> use the source, from the same thread.
> 
> take darcs stable as a medium sized example that already
> has a 'make ghci' target. by default, that target loads object
> code built by 'make' and it falls over at various places if
> one adds '-fforce-recomp' to the ghci call. using a general
> '-fobject-code' doesn't help, and having to figure out which
> modules cause ghci headaches is no fun, either.
> 
> what i'm looking for is a way to let ghci pretend as far as possible 
> that it has no limitations (compared with ghc), so that i can simply 
> load a project's main module, have no failures because of ffi, etc. 
> while still having as many of the dependencies as possible loaded in 
> source form.
> 
> is there a way to do that that works with the darcs stable
> repo example?

Not right now.  But I think the right way would be to allow `-fobject-code` 
to be used in an OPTIONS_GHC pragma to indicate that the module *must* be 
loaded as object code.  That way GHC can take it into account during the 
planning stage before starting to compile anything, because it might force 
other modules to be compiled to .o too.

http://hackage.haskell.org/trac/ghc/ticket/1365

Cheers,
	Simon