Loading GHC into GHCi (and ghcid)

[Evan Laforge]

On Fri, Jun 8, 2018 at 11:46 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> I'm slightly surprised that it keeps breaking for you, given that this is a
> core feature of GHCi and we have multiple tests for it.  You'll need to
> remind me - what were the bugs specifically? Maybe we need more tests.

Most recently, 8.2 had this problem:
https://ghc.haskell.org/trac/ghc/ticket/13604

I seem to recall an older version also had the same problem, in that
it was too sensitive about hash changes, but I think it was a plain
bug, unlike the ticket above which is arguable correct though
inconvenient.  I also remember requesting the "why did it reload"
message (e.g. flags changed, etc.), probably due to some earlier
change that made compiled modules not load.  It's been so long I
forget the details, sorry!

Currently -fdefer-type-errors is broken:
https://ghc.haskell.org/trac/ghc/ticket/14963  This is not related to
loading .o files, but ghci in general.

Also currently there's an issue where ghc uses modtime and then the
elaborate recompilation check to determine whether to recompile to
binary, but it seems ghci uses just the modtime check.  I think this
has always been there, but I'm only just noticing it recently because
of switching to git.  I don't completely understand what's going on
here yet so I may be misrepresenting the situation.

More tests would be welcome!  I guess we could compile some modules,
and ensure the binary continues to load after various kinds of poking
and prodding.  I'd be willing to contribute tests that represent my
workflow.

> There really are fundamental differences in how the compiler treats these
> two methods though, and I don't see an easy way to reconcile them. Loading
> object files happens as part of the compilation manager that manages the
> compilations for all the modules in the current package, whereas packages
> are assumed to be pre-compiled and are linked on-demand after all the
> compilation is done.

Ah, too bad.  But just out of curiosity, is there anything about the
OS level linking that's fundamentally different than ghci loading
individual .o files, or is this more a result of how ghc and ghci have
evolved?  I know you did some work to unload object files, could the
same thing be used to unload and reload packages dynamically?  Even if
it were manual, it could be a big improvement over having to shut down
and restart the whole system because a package changed.