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