Evan Laforge wrote:
Is there something that changed in 7.4.1 that would cause it to decide to interpret .hs files instead of loading their .o files? E.g.:
Brandon Allbery wrote:
I thought this was deliberate because the debugger won't work with object files?
Oh I hope not. I almost never use the debugger, and it's so much slower to re-interpret all those modules.
I am surprised about this complaint. I have never noticed any significant delay for re-interpreting, even when working on projects that are quite large, with tens of thousands of LOC. I have always found the behavior of using .o files by default surprising and annoying. The "i" in GHCi stands for "interactive". I expect work in GHCi to be as interactive as possible in every way, including having access to the debugger. I expect performance to be similar to the usual performance of interpreter shells in any language; I don't mind if it doesn't match the speed of compiled Haskell. It's nice if there is a way for experts to load .o files in GHCi, e.g., for the rare case where the performance difference for some specific module is so great that you can't work effectively interactively in some other module that imports it. There could be something to set in .ghci for people who do like that behavior all the time, perhaps. But it should not be the default. GHCi is headed in that direction in many ways, and I think that's great. I don't think more flags should be "excluded from the fingerprint" by default if that would detract in any way from the interactive experience. In particular, it is especially important for -XNoMonomorphismRestriction to be the default in GHCi. See also these tickets: http://hackage.haskell.org/trac/ghc/ticket/3217 http://hackage.haskell.org/trac/ghc/ticket/3202 Thanks, Yitz