ghci 7.4.1 no longer loading .o files?

Mon Feb 27 18:56:47 CET 2012

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.