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

[Claus Reinke]

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?

claus