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