ghci confused by hi files

[Daniel Fischer]

Am Montag, 22. Januar 2007 23:05 schrieben Sie:
> I wrote:
> >> I have observed the following weird behavior:
> >> ...ghci's ability to recognize the
> >> methods of the class seems to vary depending
> >> on whether or not hi files exist for the modules.
>
> Daniel Fischer wrote:
> > Pertinent to this is section 3.4.3 of the user's guide, "What's really in
> > scope at the prompt".
> > For compiled modules, only the exports of these are in scope.
> > So this is documented behaviour.
>
> OK, thanks, I see that now. But I would have only expected
> that to apply to modules that are _only_ compiled. If the
> source code is also available, why should I be penalized
> for compiling it?

You aren't really, you can always bring the exports of your imports into scope 
via 
:m + Oops 
(in this example). And compiled code is usually much faster than 
ghci-generated byte code. I don't know the technical reason(s) why compiled 
modules can only contribute their exports to the scope, I can only guess that 
(especially with optimisations) object code for non-exported functions might 
not be generated. Perhaps you should ask the Simons or Ian why.
>
> Preferring the source code over the compiled code by
> default would be much more convenient for iterative
> debugging. But if that cannot be the default, it would
> be nice if it were at least an option.

I'd think that debugging proceeds on a per module basis, and you would only 
need the non-exported functions of the current module (assuming all imported 
modules already debugged - if, of course, you have no import-cycle). 
Otherwise you coud temporarily comment out the export lists, so all modules 
export their whole top-level, and define
module DebugProject
	( module ProjectA
	, module ProjectB
	) where
import ProjectA
import ProjectB

ghc --make DebugProject
ghci DebugProject
Prelude DebugProject>

and everything is in scope and compiled.
Admittedly a bit inconvenient, but isn't debugging always?
>
> Thanks,
> Yitz

Cheers,
Daniel