I have observed the following weird behavior: When I define an instance of a certain MPTC in a separate module from the definition of the class, ghci's ability to recognize the methods of the class seems to vary depending on whether or not hi files exist for the modules. I am using the current Debian build of GHC 6.6. Below are a set of three files that reproduce the behavior, and a shell session that demonstrates it. Before I compile the program, ghci works fine. After I compile with ghc - thus generating hi files - ghci gets confused. Then I delete the hi files and everything is fine again. Thanks, Yitz -- File Oops.hs {-# OPTIONS_GHC -fglasgow-exts #-} module Oops where class Oops a b c | a -> b c where foo :: a -> b -> a -- File Whoops.hs {-# OPTIONS_GHC -fglasgow-exts #-} module Whoops where import Oops instance Oops String Int Bool where foo x n = show (x, n) -- File runWhoops.hs module Main where import Whoops import Oops main = putStrLn $ foo "bar" 42 $ ghci Whoops / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. Loading package base ... linking ... done. [1 of 2] Compiling Oops ( Oops.hs, interpreted ) [2 of 2] Compiling Whoops ( Whoops.hs, interpreted ) Ok, modules loaded: Oops, Whoops. *Whoops> foo "baz" 7 "(\"baz\",7)" *Whoops> Leaving GHCi. $ ghc --make runWhoops.hs [1 of 3] Compiling Oops ( Oops.hs, Oops.o ) [2 of 3] Compiling Whoops ( Whoops.hs, Whoops.o ) [3 of 3] Compiling Main ( runWhoops.hs, runWhoops.o ) Linking runWhoops ... $ ghci Whoops / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. Loading package base ... linking ... done. Ok, modules loaded: Oops, Whoops. Prelude Whoops> foo "baz" 7 <interactive>:1:0: Not in scope: `foo' Prelude Whoops> Leaving GHCi. $ rm *.hi $ ghci Whoops / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. Loading package base ... linking ... done. [1 of 2] Compiling Oops ( Oops.hs, interpreted ) [2 of 2] Compiling Whoops ( Whoops.hs, interpreted ) Ok, modules loaded: Oops, Whoops. *Whoops> foo "baz" 7 "(\"baz\",7)"
Am Dienstag, 16. Januar 2007 12:12 schrieb Yitzchak Gale:
I have observed the following weird behavior:
When I define an instance of a certain MPTC in a separate module from the definition of the class, ghci's ability to recognize the methods of the class seems to vary depending on whether or not hi files exist for the modules.
This has nothing to do with MPTC's, the same behaviour occurs with H98 typeclasses. 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. Fix: re-export Oops from Whoops. Cheers, Daniel
I am using the current Debian build of GHC 6.6.
Below are a set of three files that reproduce the behavior, and a shell session that demonstrates it.
Before I compile the program, ghci works fine. After I compile with ghc - thus generating hi files - ghci gets confused. Then I delete the hi files and everything is fine again.
Thanks, Yitz
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? 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. Thanks, Yitz
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
participants (2)
-
Daniel Fischer -
Yitzchak Gale