ghci confused by hi files
daniel.is.fischer at web.de
Tue Jan 23 10:15:53 EST 2007
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
: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 ProjectA
, module ProjectB
ghc --make DebugProject
and everything is in scope and compiled.
Admittedly a bit inconvenient, but isn't debugging always?
More information about the Glasgow-haskell-users